Refine linear memory aliasing #455
Conversation
|
Oops, forgot about this. Any objections? |
|
lgtm |
| [Web](Web.md#aliasing-linear-memory-from-JS) would reflect exported linear | ||
| memory to JS as an `ArrayBuffer`. The MVP does not currently provide for | ||
| *importing* linear memory though this may be added | ||
| [in the future](FutureFeatures.md#importing-linear-memory). |
There was a problem hiding this comment.
I'm pretty wary of how this will interact with multi-threading and SAB. In C++ it's a bit of a fiasco to use shared memory:
volatileshould be used to denote external modification, so the compiler remains conservative.std::atomicshould be used to enforce ordering and no-tear (yes, in addition tovolatile).- Non-lock-free atomics are guaranteed to work in an address-free way within the same process but definitely do not work when using shared memory across processes.
This makes me wary of specifying things as you've outlined here without properly understanding what this implies for threads in WebAssembly. Does it entirely prevent optimizations? Valid reordering? 64-bit atomics on some platforms?
I'm OK specifying this as you've done fi you think it'll move stuff forward, but I insist on opening an issue with the above text, to revisit before MVP so we're not stuck when we want to add threads.
WDYT?
There was a problem hiding this comment.
I'm having trouble understanding your specific concern. At the top you mention wasm+SAB interactions but then the rest of your comment seems to be general memory model concerns that are not specific to SAB. There are some real concerns about resize+mprotect/SAB interactions outlined in Web.md, but those are quite different than what you're talking about here. Moreover, we have agreed that, because threads (not just SAB interactions) are such a cross-cutting concern, that we should have a good experimental prototype up and working before v.1 is finished; that's #104. So I'm not sure what specifically goes in a new issue.
There was a problem hiding this comment.
The text reads as "oh I can just say externally alias and then everything works" but I see it as an undefined hole in the memory model. A hole we can plug, but will require some pretty serious design work that I'm not sure we want to tackle for MVP considering C++ hasn't gotten it right either.
That being said, maybe we can go with it for now, I can open an issue, and we can revisit when we have a clearer idea backed by code?
There was a problem hiding this comment.
sgtm, happy to discuss more in that issue.
Refine linear memory aliasing
This PR adds some more details to how linear memory is exported to JS from WebAssembly in Web.md to reflect more recent discussions concerning the hazards of resizing,
mprotectand threads.Heap exports also begs the question of heap imports which this PR takes the liberty of adding to FutureFeatures.md.