Tracking Phase 4 Requirements

[ashleynh]

This is an issue to track the requirements needed to move multi-memory into Phase 4.

• [x] Two or more Web VMs have implemented the feature and pass the test suite
  • [x] V8
  • [x] Firefox
• [x] At least one toolchain has implemented the feature
  • [x] Binaryen
• [x] The spec document has been fully updated in the forked repo.
• [x] The reference interpreter has been fully updated in the forked repo and passes the test suite.
• [ ] The Community Group has reached consensus in support of the feature and consensus that its specification is complete.

  • 6

  • 34

I plan to propose the advancement to Phase 4 after we meet these requirements. Please reply if there are any remaining concerns for the phase advancement that are not listed here.

[rossberg]

Yes, spec/interpreter/test-side all boxes have been checked 4 years ago, just waiting for implementations to catch up. :) Happy to see progress on this!

[ashleynh]

Awesome! I went ahead and added an agenda item to vote Multi-Memory to Phase 4 at the in-person CG meeting, https://github.com/WebAssembly/meetings/pull/1361

[dtig]

Should this proposal have a JS API that exposes multiple memories, or has some way that additional memory can be accessed from outside of Wasm? A straightforward extension could be to extend the memoryDescriptor to take an index an optional memory index parameter to the and existing WebAssembly.Memory JS API functions.

The reason for proposing this is that without support in the compilation pipeline in the tools (someone should correct me if the Binaryen implementation is sufficient for use from a source language), or API functions in the Spec, the use of multiple memories is limited to within Wasm. While I'm not sure if there are applications that could benefit from this, adding an easily accessible API potentially encourages experimentation with the proposal, and/or usage in the future for applications.

[dschuff]

https://github.com/WebAssembly/multi-memory/pull/27 raised the limit on the number of memories in the JS API from 1 to 100. I'm not sure anything more needs to be done to the JS API specifically, since IIUC the core spec rules allow any memory to be exported or imported; so I think it wouldn't be the memoryDescriptor that describes which index a memory is in, but the module's imports (and the corresponding objects that satisfy them at instantiation time).

[rossberg]

What @dschuff said, the JS API shouldn't need anything to support this, as nothing in it depends on the fact that only a single memory can currently occur in import or export lists of a module. (Memory indices are not relevant or meaningful outside a module.)

[dtig]

Thanks both! Talked this through with @dschuff, and I was working backwards from how do you distinguish which buffer belongs to which memory with multiple memory imports/exports. Leaving a little bit of detail here if it helps anyone else. For imports, the memory object is created outside of Wasm, and the index itself isn't meaningful, but can be queried from the memory object itself. Similarly named exports on instantiation should be sufficient to distinguish which between multiple exported memories.

[rossberg]

For imports, the memory object is created outside of Wasm, and the index itself isn't meaningful, but can be queried from the memory object itself.

Hm, did you mean "and cannot be queried from the memory object itself"? Runtime objects like memory instances do not carry indices in any form, they are merely "bound" to indices (possibly multiple ones) inside a given module. Indices are like local variable names.

[dtig]

For imports, the memory object is created outside of Wasm, and the index itself isn't meaningful, but can be queried from the memory object itself.

Hm, did you mean "and cannot be queried from the memory object itself"? Runtime objects like memory instances do not carry indices in any form, they are merely "bound" to indices (possibly multiple ones) inside a given module. Indices are like local variable names.

Sorry I phrased the sentence wrong, the index isn't meaningful, and the buffer can be queried from the memory object (not index as implied).