Multi-memory support in AssemblyScript?

[titzer]

Feature suggestion

Hello, the WebAssembly multi-memory proposal has advanced to Phase 3, and there are several engines that have implemented the proposal. One perennial problem is that no mainstream language has support for multiple memories, so there is a bit of a chicken-and-egg problem. However, there are several important use cases for multiple memories, such as virtualizing/layering APIs, linking, and instrumentation with Wasm.

I filed https://github.com/WebAssembly/multi-memory/issues/45, where some discussion is happening on how this would work for C/C++ (and maybe by extension, Rust, using LLVM?).

I'm curious if there are any plans on supporting multiple memories in AssemblyScript?

[dcodeIO]

I believe support for multi-memory wouldn't be too hard to add to the respective intrinsics, though some of them would become a little unweildy (e.g. store<T>(ptr: usize, value: auto, immOffset?: usize, immAlign?: usize, immMemory?: i32))). Also, last time I checked, Binaryen was occasionally missing arguments for the necessary memory immediate on some C API functions. Affected functions might be SIMD, threads, GC and/or stringref related iirc. Not entirely certain about the current status there.

[ashleynh]

Binaryen has arguments for the necessary memory immediate on SIMD and threads. GC doesn't have memory needs afaik, but you're right, Binaryen has no support of multi-memory in stringref. Let me know if there are any other C API functions you run into that are missing the memory argument.

[tareksander]

I'd like to use multiple memories for an ECS system, what's the status on this? I wouldn't need many features, just a memory immediate for the standard WASM types.

[HerrCai0907]

it is not too hard to add some builtin load / store api to support multiple memory. But if we want to integrate the whole as with multiple memory, The major issue is how can we map the current allocator and gc object to multiple memory.

[tareksander]

C++ (and Rust as an experimental feature) have allocator interfaces and you can specify the allocator to use for the standard library collections when instantiating them. Full language support would likely need to tag pointers with the memory index they point to at compile time (because IIUC the load instruction only take a memory index immediate, so the destination has to be known at compile time) and/or you specify a range of memories as a compiler option for which simple functions with all the load/store operations for each memory are generated to allow dynamic access (that would then need something like a fat pointer type which has the dynamic memory index included). You would then instantiate an allocator for each additional memory you want. I don't know enough about garbage collectors to know if it is even possible to have multiple GCs in a program like this. Are there destructors in AssemblyScript? I think using a traditional allocator in another memory with reference-counted pointers should be no problem, right?

For my use case that's all unneeded: I made a generator for accessing structures in ArrayBuffers with Typescript type support, and I could easily make it so that AssemblyScript functions to load and store are generated, too. Since the number and order of memories is defined for me, I can make simple access functions with the memory index immediate. I only need the WASM builtins with a memory immediate.