[wasm] Exploit unallocated zero page to remove null checks in jiterpreter #86403
Conversation
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsThe zero page is unallocated, which means that reading the string/array length fields of a null pointer will return a length of 0. The bounds check for getchr and getelema1 will thus fail, causing us to bail out as if we had done a null check. This lets us remove a compare and a branch in all cases. Also skip emitting a const+add pair in a few places where we add offsets to pointers if we know the offset is 0, since it'll make traces slightly smaller.
|
|
Shouldn't reading a null ref throw a different exception ? |
On failure, we will bail out to the interpreter, and it will retry the opcode and do a null check. I think we could apply this same optimization to AOT - if the bounds check fails, then null-check the array reference and throw the correct exception. |
|
Since there's a risk this might cause obscure issues I think I'll merge it after we branch this preview. Based on emscripten-core/emscripten#19389 as long as we don't change our emscripten config, it should be safe in Release runtime builds but not in Debug ones. |
I'm a little bit concerned that release and debug builds will have different null-checking behavior. Also users who set If we always set |
|
mono_wasm_is_zero_page_reserved should do the trick I think. |
|
is this still no-merge? |
I don't want to add it to p5, I think it's risky. |
|
While looking into one of Jerome's bug reports, I noticed that there was garbage data at offset 0 in the heap that shouldn't be there. Not sure how that scenario came to be, will try to understand whether something about this optimization is unsafe for a new or different reason. |
Reproduced this in another build, and thankfully |
…d getchr Disable zero page optimization in debug builds Sense whether zero page optimizations are safe based on the location of the emscripten stack
Improve jiterpreter stats formatting
The zero page is unallocated, which means that reading the string/array length fields of a null pointer will return a length of 0. The bounds check for getchr and getelema1 will thus fail, causing us to bail out as if we had done a null check. This lets us remove a compare and a branch in all cases.
Also skip emitting a const+add pair in a few places where we add offsets to pointers if we know the offset is 0, since it'll make traces slightly smaller.