-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change WASM direct heap access to use helper functions #61355
Conversation
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsAccording to the ECMAScript spec, the left-hand side of an assignment is evaluated before the right-hand side. This means that for the following statement:
The write will be discarded if the heap grows during the call to Since almost any JS expression can secretly be invoking a property getter, the best solution for this is to do roughly what blazor does, and perform memory accesses through functions so that we can be certain the offset and value will be evaluated before the target is evaluated. With this approach, the above becomes:
|
…not backwards-compatible to change it or use BigInt
I spent a bit trying to use BigInt to properly implement I64/U64 because Emscripten's setvalue/getvalue for them turn out to be broken, but it seems to not be possible to do that without breaking existing code. |
According to the ECMAScript spec, the left-hand side of an assignment is evaluated before the right-hand side. This means that for the following statement:
Module.HEAPU32[offset] = get_value();
The write will be discarded if the heap grows during the call to
get_value
. If the offset itself is a property with an accessor or the return value of a function call the problem applies there too. This is because heap growth requires creating a new set of typed arrays pointing at the new larger heap buffer, and the old arrays become 'detached', and all reads/writes to a detached buffer will silently fail.Since almost any JS expression can secretly be invoking a property getter, the best solution for this is to do roughly what blazor does, and perform memory accesses through functions so that we can be certain the offset and value will be evaluated before the target is evaluated. With this approach, the above becomes:
INTERNAL.setU32(offset, get_value());