[wasm] Implement MONO_MEMORY_BARRIER in jiterpreter #107325
Conversation
|
Should this be just a no-op in single threaded wasm? |
|
Right now jiterp is disabled in MT, so we need to enable it in order to test this PR. runtime/src/mono/mono/utils/options-def.h Line 92 in 6e68f92 |
|
I'll do a few runs with traces enabled for MT tomorrow. |
kg
force-pushed
the
jiterp-memory-barrier
branch
from
26ad367 to
8de6f60
Compare
| // The text format and other parts of the spec say atomic.fence has no operands, | ||
| // but the binary encoding requires a dummy zero byte for some reason |
There was a problem hiding this comment.
It's for the memory ordering. See this part of the shared everythign threads proposal. 0 means sequential consistency, 1 will mean acquire-release https://github.com/WebAssembly/shared-everything-threads/blob/main/proposals/shared-everything-threads/Overview.md#memory-orderings
There was a problem hiding this comment.
And sync_synchronize is sequential consistency, right?
There was a problem hiding this comment.
And sync_synchronize is sequential consistency, right?
It's a "full barrier" which presumably means seq cst. https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html
…p traces (dotnet#107325) * Implement MONO_MEMORY_BARRIER in jiterpreter * Enable jiterp traces for MT wasm
…p traces (dotnet#107325) * Implement MONO_MEMORY_BARRIER in jiterpreter * Enable jiterp traces for MT wasm
This opcode is fairly high in the abort statistics for System.Runtime.Tests, so it's worth the trouble to wire it up
Fixes #100273