"externally aliasable" + memory model

[jfbastien]

As discussed in #455 (comment), the concept of "externally aliasable" modules has unclear implications on WebAssembly's memory model.

In C++ it's a bit of a fiasco to use shared memory:

• volatile should be used to denote external modification, so the compiler remains conservative.
• std::atomic should be used to enforce ordering and no-tear (yes, in addition to volatile).
• 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 outlined in Module.md by #455 without properly understanding what this implies for threads in WebAssembly as well as what it implies for the embedder (e.g. on the web what does this mean for SharedArrayBuffer). Does it entirely prevent optimizations? Valid reordering? 64-bit atomics on some platforms?

Note that "externally aliasable" is a very desirable feature to reduce the amount of copying and to expose idiomatic APIs to WebAssembly.

We don't need to tackle this now, but we need to make sure MVP doesn't over-constrain us. Let's revisit before MVP.

[lukewagner]

Ah, I think I understand what you are getting at now: is the idea that perhaps there is some optimization/implementation that would be valid if the only readers/writers to shared memory was wasm code in the same instance but because of this unknown "external alias", we'd be unable to do the optimization?

If so, it seems like we're in a similar situation as we are with function imports/exports and it'd be up to the host environment to define the meaning and thus the wasm spec wouldn't be a priori committing hosts to any memory model guarantees beyond a single instance. For the web environment when wasm exports to JS, it seems like we'd model JS SAB get-elems/set-elems as wasm loads and stores and JS Atomic ops as the analogous wasm atomic ops. There is, of course, the independent challenge of specifying the memory model itself, but what I'm not currently seeing and would be interested to hear about are new corner cases arising from wasm+JS interactions that aren't addressed by modeling one in terms of the other. (cc'ing @lars-t-hansen)

[jfbastien]

Now obsolete, closing.