This issue was opened a while ago so I wanted to ask again whether there was any way that we know currently to leverage multi-memory in the WASM target for Rust.
My use-case exactly is that I have separate WASM modules that all need to have their own heap, but for maximum efficiency, I have an ECS world that I wish to store in a separate, shared WASM memory.
That ECS world will be given, one at a time, to different WASM modules to do what they will with it, but I dont' want to copy that world, back and forth, so I want to put it in one shared memory.
The issue is how to interact with that other memory in Rust. I don't see anything in core::arch::wasm32 and it looks like the inline assembly macro doesn't work on wasm32, so I'm not sure exactly how to go about supporting my use-case yet, and I wanted to see if anybody has any ideas.
I'm not sure LLVM supports multi-memory. In any case rust doesn't support multiple segments (which wasm multi-memory effectively is) at all. Even on targets where LLVM does support it. Using multiple segments requires tagging every reference and pointer (or at least every load/store) with the right segment to use.
As an alternative solution, maybe we could create a custom global allocator in Rust that would only allocate memory in a whitelisted memory space.
Then we'd have to have a way for different Rust WASM modules to allow the embedder to specify which memory region Rust is allowed to allocate memory in.
This would mean it would be harder to grow the WASM memory, because with multiple modules all using the same memory space you'd have to have coordination from the embedder to make sure they didn't step on each-other's heaps when allocating.
And it would make it harder to inter-op with other languages, because they'd all have to be able to make the same workaround.
Or maybe we just need a custom allocator that stores it's state in a specific place in the WASM memory, and then we just make sure all Rust WASM mods use the same custom allocator, so that all the different WASM modules can share the same heap without issues.
Then it looks like we could support AssemblyScript, too, by overriding the memory allocator with a custom runtime.
If it worked for AssemblyScript and Rust, that would be enough for me, though I might need to make an identically functioning allocator in both languages to make that work.