This repository was archived by the owner on Apr 25, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 25, 2025. It is now read-only.
Tracking Phase 4 Requirements #50
Description
This is an issue to track the requirements needed to move multi-memory into Phase 4.
- Two or more Web VMs have implemented the feature and pass the test suite
- V8
- Firefox
- At least one toolchain has implemented the feature
- Binaryen
- The spec document has been fully updated in the forked repo.
- 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.
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.
Activity
rossberg commentedon Sep 12, 2023
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 commentedon Sep 12, 2023
Awesome! I went ahead and added an agenda item to vote Multi-Memory to Phase 4 at the in-person CG meeting, WebAssembly/meetings#1361
dtig commentedon Sep 19, 2023
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
memoryDescriptorto 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 commentedon Sep 20, 2023
#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
memoryDescriptorthat describes which index a memory is in, but the module's imports (and the corresponding objects that satisfy them at instantiation time).rossberg commentedon Sep 20, 2023
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 commentedon Sep 21, 2023
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 commentedon Sep 22, 2023
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 commentedon Sep 22, 2023
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).