Exporting wasm table and memory rather than importing them

[Sam Clegg]

I recently made a change to start exporting the table from the WebAssembly module:

https://github.com/emscripten-core/emscripten/pull/12296

I'm hoping to followup with a similar change for the WebAssembly memory (a.k.a `wasmMemory):

https://github.com/emscripten-core/emscripten/issues/12315

If we go ahead with this change it will mean the WebAssembly module is in charge of creating and exporting the memory rather than JavaScript.  One potential downside here is that it removes the ability to adjust the memory size and runtime, or supply your own memory (i.e. it removes the ability to set `wasmMemory` or `INITIAL_MEMORY` on the Module object.

However there are many upsides to doing this:

- Reduced JS size and complexity

- Consistency with standalone more

- WebAssembly is more self-contained

- Easier to load and run emscripten-built WebAssembly modules in other environments.

I'd like to found out how many developers out there are settings `wasmMemory` or `INITIAL_MEMORY` at runtime to see how likely it is that we might be able to make this switch.  Is possible of course that we could support both modes.. although I would prefer not to.

cheers,

sam

[キャロウ マーク]

I still hope to investigate using a hand-written wasm module as a library called from an Emscripten compiled program. To do this I will need to be able to get each to use the same malloc and wasmMemory. Will this change prevent such a thing from being done?

Regards

    -Mark

[Floh]

From what I'm seeing in settings.js, INITIAL_MEMORY has the same behaviour as the old TOTAL_MEMORY? If I remember right I still had to set that in WASM if the initial memory usage of my code is bigger than the default initial memory size (for instance when using very big, uninitialized global variables, those don't bloat the WASM module size, but can result in a big initial memory requirement), otherwise WASM startup would fail.

As long as this situation (very big global variables) works automatically, I think I'm fine with the change :)

[Floh]

Ah never mind, I missed the whole "at runtime" part. 

[Sam Clegg]

On Wed, Sep 23, 2020 at 4:55 PM キャロウ　マーク <git...@callow.im> wrote:

I still hope to investigate using a hand-written wasm module as a library called from an Emscripten compiled program. To do this I will need to be able to get each to use the same malloc and wasmMemory. Will this change prevent such a thing from being done?

That should not be a problem, the `malloc` function along with the wasm memory are still available to you, once the module has been instantiated.

 

Regards

    -Mark

On Sep 23, 2020, at 14:53, 'Sam Clegg' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

I recently made a change to start exporting the table from the WebAssembly module:

https://github.com/emscripten-core/emscripten/pull/12296

I'm hoping to followup with a similar change for the WebAssembly memory (a.k.a `wasmMemory):

https://github.com/emscripten-core/emscripten/issues/12315

If we go ahead with this change it will mean the WebAssembly module is in charge of creating and exporting the memory rather than JavaScript.  One potential downside here is that it removes the ability to adjust the memory size and runtime, or supply your own memory (i.e. it removes the ability to set `wasmMemory` or `INITIAL_MEMORY` on the Module object.

However there are many upsides to doing this:

- Reduced JS size and complexity

- Consistency with standalone more

- WebAssembly is more self-contained

- Easier to load and run emscripten-built WebAssembly modules in other environments.

I'd like to found out how many developers out there are settings `wasmMemory` or `INITIAL_MEMORY` at runtime to see how likely it is that we might be able to make this switch.  Is possible of course that we could support both modes.. although I would prefer not to.

--
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/34853692-E256-4C4D-BC4D-F5AEAFAB7CD5%40callow.im.

[Brion Vibber]

Out of curiosity, how does pthreads handle this? I'd been under the impression that importing the existing memory was required when instantiating the module on each worker.

-- brion

--

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/CAL_va2-fPnnf6bn8hBiETQLehyZ_TRWQOE2vSS9%3DQ7y2B1nd0g%40mail.gmail.com.

[Sam Clegg]

On Thu, Sep 24, 2020 at 10:19 PM Brion Vibber <br...@pobox.com> wrote:

Out of curiosity, how does pthreads handle this? I'd been under the impression that importing the existing memory was required when instantiating the module on each worker.

Yes you are correct, I think pthreads and dynamic linking are two situations where we would need to continue to use imported memory (and most likely imported table).    

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAFnWYT%3D11eBxve_vpnv1J3GvqvT-DeECZJbfv4wsVn8rm7Vd6A%40mail.gmail.com.