How many times does WebAssembly.instantiate() need to be called?

[nepx]

Hi,

I'm trying to compile a number of command-line applications to WebAssembly via Emscripten, but along the way I realized that synchronous invocation of these commands is a must. After some inspection, I've come to realize that the main drawback is using WebAssembly.instantiate, an async/Promise function.

Right now, I pre-download a module using XHR and pass it through WebAssembly.compile, then passing that compiled module to WebAssembly.instantiate every time this command-line app needs to be run. Unfortunately, both aren't synchronous.

To illustrate, if I wanted to call ls three times in a row, I'd call the following functions:

execSync("ls");
execSync("ls");
execSync("ls");

The problem is that each time ls is run, it needs to be instantiated again (WebAssembly.instantiate) to give it a clean state, which breaks the synchronous nature of this code (I don't like this either, but it is what it is). Is there a way that I can instantiate it just once and reuse that for all subsequent invocations? Are there any hidden "gotchas," like dirty memory that needs to be cleared or WASM globals that need to be set to 0?

Thanks in advance!

[kripken]

The simplest option may be to build the program more as a library, and then to call an export multiple times. It's true that memory and global state can be an issue, so you'd need to make that export clean up whatever needs to be. If the application has a lot of global state that it modifies and then forgets about, that might be hard, though.

Another option is to use -s WASM=0, that is avoid wasm. A JS build with asynchronous compilation turned off is fully synchronous.

[nepx]

Theoretically, if you reset the memory (i.e. memset(NULL, 0, memorySize) and globals to their original values, would it do the same thing as re-instantiating a module? My plan is to separate the generated WASM code from the JS runtime, taking responsibility over the implementation of the system calls, so resetting Emscripten state wouldn't be a problem.

Ideally, I would like to run programs unmodified in the browser, not just compiling them to a library and calling individual functions. That means at some point, I'd have to call the main (or _start) function with argc and argv, etc. My only question is: is there a way that I could call main repeatedly without having to reinitialize the module?

asm.js is definitely something interesting that I'll look into, thank you.

[kripken]

Emscripten output also has global state in JS, unless you use standalone wasm and have no JS. In general there is no simple way to reset it, not without creating a new setup like the modularize factory function does, unless you happen to use a small subset and can hack things somehow. That seems risky, though - I'd recommend the other options - sync non-wasm startup, or standalone wasm.

[nepx]

Does standalone WASM link in libc and friends and expose system calls? All I need access to are the raw system calls that either the program or libc call (and I'd need to do that, async instantiation or not), and per-process state could be handled accordingly in the custom syscall code.

Re-instantiating an asm.js module is certainly a viable option, but I'm worried about the memory usage, compiling the same code over and over again.

[kripken]

Standalone wasm links in libc etc. normally. It also tries to do more in libc to avoid depending on JS as much as possible. For things it has to call out to JS, it still does (like printing).

Re-instantiating the JS module may not be as bad as you think. The JS engine should not recompile the same code again after it compiles it once (just like it doesn't recompile closures repeatedly, barring type changes), at least not unless it's in a separate window or worker.

[nepx]

Thanks for the replies! I feel like we're getting closer and closer to a solution...

Which functions would I need to implement if I used standalone WASM? From what you said, would I have to implement printf myself, or would I just have to handle something like write(1, "Hello world!\n", 13)? The latter is preferable, in my case.

Ideally, I'd like to implement all of the system calls myself; there are quite a few things that I'd like to handle manually. Is this possible at the moment?

[kripken]

It might be best to look at the wasm output to see what you need to implement, concretely. But it will link in libc, so it will be a syscall - the WASI fd_write syscall I believe. So that sounds like exactly what you want.

[nepx]

Is there any way to read/write WASM globals in JS, and, furthermore, is there a way to recover their original values? It would be ideal to do this all in JS, without the need for patching the generated module.

[kripken]

Not really. The global would need to be exported so JS can access it, which means modifying the module.

[nepx]

Would it be possible to use Binaryen to add a reset() procedure, where all the globals are reset? The idea is to patch the WASM binary to include another function that resets global state (and perhaps memory). Or is there a simpler, more elegant way of doing this?

[kripken]

Sure, you could use binaryen to modify the wasm that way.

I do think the other options mentioned are better, though - sync compilation using JS should be easy and fast (the VM will optimize repeated calls) as I said. But if you absolutely need the speed of wasm over JS, then a binaryen pass to add such a "reset" button would make sense. I'd support such a PR upstream.

[nepx]

For anyone that's been following the issue, I've found a solution to sync instantiation: use Web Workers. This also fixes some other problems with async calls, so that's nice.

Is there any way to abandon the WASI bindings and simply use the raw system calls (i.e. env.__syscall220) themselves, or is this not advisable? At the moment, there are quite a few env. functions that need to be implemented, like env.localtime, and I'd like to avoid writing out implementations of C standard library functions.

[nepx]

As I believe this issue has been somewhat settled, and a few avenues explored, I think this issue could be considered somewhat satisfactorily solved.

For those having the same issue as me, I ended up using Web Workers because they allow for synchronous initialization, although some of the other strategies explored in the issue comment chain here might work in the case that they're not available.