How to provide your own wasm memory

[Joshua Minter]

The two "documented" (albeit barely) methods for providing your own memory buffer are:

- Module['buffer'] which according to the code will create the memory buffer but not setup the wasmMemory object and thus crash. Confirmed from testing

- Module['wasmMemory'] which according to the code will be only used when compiling for pthreads. Also confirmed from testing

[Jukka Jylänki]

In asm.js builds defining Module['buffer'] is enough. In wasm builds
you need to provide both Module['wasmMemory'] and Module['buffer'].
The use case of providing a precreated memory buffer was strongly
defined for asm.js, not sure how well we support it currently for
wasm. One complication there is that the size of the wasm heap is
pre-defined in the .wasm module file, so when precreating your own
memory, you will need to create it with the same size that the .wasm
module expects. (That limitation may be a reason that providing your
own Module['wasmMemory'] might not work that well out of the box but
you may need to do some custom hacks to the preamble&postamble)

> --
> You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/ff3defe7-b46a-4fad-9033-27623fdaed3a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Joshua Minter]

Module['wasmMemory'] only seems to be supported when USE_PTHREADS (and MODULARIZE on second look) is enabled. See preamble.js at lines 48 and 1136.

As for requiring the same size as the wasm module how does that work for growing memory? Does it need to be the same initial size?

Our specific use case is that we need to completely reset the module and rerun and our current solution is to just scrap everything and load it all again. However, this causes alot of memory issues so we keep the memory heap around and try to reuse it. I am currently looking into alternative ways to restart the emscripten module.

[Alon Zakai]

Yes, I think we have to receive the memory in a special way in workers in pthreads+modularize mode. So the goal isn't to support users providing their own memory, but to make things work at all in workers.

If this is useful - and your use case sounds reasonable! - then we should fix this. PR would be welcome. One thought is that perhaps this should be behind a flag, as it will increase code size (the optimizer won't be able to remove it statically), and we prefer to not do that.

--

You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/44e6fc91-1771-437c-8ebc-eb9c2b9cf146%40googlegroups.com.

[Joshua Minter]

I'm happy to work on and submit a PR, I just have a few questions:

- should I use Module['buffer'], Module['wasmMemory'] or something else? My thinking would be to use wasmMemory since its already there and partially documented.

- if this is gonna be put behind a flag, should the option to provide your own Module['buffer'] also be put behind a flag (potentially the same one)? It seems odd having one behind a flag and the other not especially since Module['buffer'] isn't even very usable for WebAssembly. However, putting it behind a flag could potentially break compatibility.

[Joshua Minter]

I have created a PR

[Joshua Minter]

The PR is finished and ready for review. At this point is provided with Module['wasmMemory'] and I made both that and Module['buffer'] available without a flag. I also gave the whole buffer initialization code a rewrite and cleanup.