Add memory exports

[lukewagner]

When memory is exported, it needs to be given a name and exported into the same namespace as the normal (function) exports. In the future, other kinds of things may be exported too (for example, the immutable load-time-initialized global "symbols" needed for dynamic linking). All this suggests changing export to be a union of ExportFunction and ExportMemory (and other cases in the future).

[ppopth]

1. Why do we need to export the entire memory?
   I think if we want to catch the idea of exported global variable we should export the segments instead.
2. Is this already defined in the design repo?

[lukewagner]

On the Web platform, memory exporting means that JS gets an ArrayBuffer that aliases the instance's linear memory. This is useful for being able to efficiently move data into and out of wasm linear memory. In the MVP, all access to web APIs necessarily thunk through JS so this can save a lot of copying for web APIs taking a typed array. Over time (with WebIDL integration) it should become unnecessary for pure C++ apps. However, for cases where wasm is being mixed in as part of a bigger webapp with JS, I expect memory-exporting would continue to be useful for a long time. This feature has been in the design repo since almost the beginning (it's a basic requirement for Emscripten); currently in Modules.md#linear-memory-section.

[titzer]

In the binary format there is just a bit to declare that the memory is
exported or not. It's always just called 'memory'. Is the risk of a name
collision very big here?

On Wed, Feb 17, 2016 at 3:28 PM, Luke Wagner notifications@github.com
wrote:

On the Web platform, memory exporting means that JS gets an ArrayBuffer
that aliases the instance's linear memory. This is useful for being able to
efficiently move data into and out of wasm linear memory. In the MVP, all
access to web APIs necessarily thunk through JS so this can save a lot of
copying for web APIs taking a typed array. Over time (with WebIDL
integration
https://github.com/WebAssembly/design/blob/master/GC.md#webidl-integration)
it should become unnecessary for pure C++ apps. However, for cases where
wasm is being mixed in as part of a bigger webapp with JS, I expect
memory-exporting would continue to be useful for a long time. This feature
has been in the design repo since almost the beginning (it's a basic
requirement for Emscripten); currently in Modules.md#linear-memory-section
https://github.com/WebAssembly/design/blob/master/Modules.md#linear-memory-section
.

—
Reply to this email directly or view it on GitHub
#243 (comment).

[lukewagner]

It just seems ad hoc and irregular, esp if we later have other kinds of exports. Also, given that export names will end up controlled by user code, yes, collision is a real concern (just like magic properties __proto__ on Object.prototype end up being a problem when people use objects as hash tables and test with in.

[jfbastien]

I'm for exporting the entire memory in MVP (@lukewagner's spec impl), but against exporting subsets: IMO subsets of memory exports are the same as cross-process shared memory from the POV of the wasm user. We need a solid design and we should consider what's been done before (export handles / IDs versus named shared memory, ...). The complexity tells me we should punt post-MVP and go with the simpler thing @lukewagner has now.

[ppopth]

Is there any where other than spec already implement this memory export ?

[lukewagner]

v8 and SpiderMonkey (using the proposed syntax in this PR).

[rossberg]

LGTM, if it's fine with everybody else.

[lukewagner]

This PR made sense to me when memory exports were injected into the same namespace as function exports. More recent discussions suggests exports would have their own namespace object and memory would be separate, so it seems fine to stay with the current v8 design of:

• make "exported" a flag in the "memory" section
• fix the name of the exported memory to memory (since it can no longer collide accidentally)

That suggests reverting this patch and just adding an exported bool to memory' (and a corresponding s-expr syntax). @titzer @rossberg-chromium Is that right?

[titzer]

SGTM

On Fri, Feb 26, 2016 at 12:16 PM, Luke Wagner notifications@github.com
wrote:

This PR made sense to me when memory exports were injected into the same
namespace as function exports. More recent discussions suggests exports
would have their own namespace object and memory would be separate, so it
seems fine to stay with the current v8 design of:

• make "exported" a flag in the "memory" section
• fix the name of the exported memory to memory (since it can no
  longer collide accidentally)

That suggests reverting this patch and just adding an exported bool to
memory' (and a corresponding s-expr syntax). @titzer
https://github.com/titzer @rossberg-chromium
https://github.com/rossberg-chromium Is that right?

—
Reply to this email directly or view it on GitHub
#243 (comment).

[lukewagner]

Actually, thinking about this more: the reason for making memory a special kind of export is that it would need a getter on the proto (to be able to issue different ArrayBuffers over time). However, if we have a first-class Wasm.Memory object that encapsulates linear memory, we don't have this problem (the Wasm.Memory object would stay valid through resizes) and thus memory can be a simple property value just like function exports and live in the same namespace. So then I think this PR was the right design after all.