Making it possible to "clone" an initialized store

[tonyhb]

Hi peeps, playing around with wazero for fun - it's awesome! I'm currently using wazero to run wasi based libraries within Go. The library is built in Rust, and I was testing FFI vs Wazero because, well, it sounded interesting.

After implementing the basics, I'm noticing:

• Instantiating a new store and interpreter takes the bulk of the time. For my library, that's anywhere from 400ms to 1.5 seconds.
• wasi and wasm doesn't de-allocate memory via free(), so when I allocate memory in the library to pass objects (eg. strings, structs), they're never going to be cleaned up. memory grows linearly with usage.

So, that leaves you with a couple options to manage speed vs memory growth:

• Create a new env in a separate goroutine when memory usage grows to a specific level, then atomically swap envs to reclaim space
• Or, allow an instantiated Store to be cloned once initialized so that we can use the fresh state for each library invocation.

I've played around with cloning a store, but it's quite a pain. Theoretically, is this something that wazero would ever enable? Is there something I'm missing here?

Also, I haven't looked into JIT and this is only for the interpreter engine as ... well, I'm on debian arm, and i want to produce static builds for every OS & arch 😬

[mathetake]

Thanks @tonyhb, this is a reasonable feature request because some of the other runtimes can actually clone stores (or module instances) for example wasmtime: https://docs.wasmtime.dev/api/wasmtime/struct.Module.html#modules-and-clone

Currently it's not possible to clone ModuleInstance or Store type as we haven't coded wazero so it can be cloned, but we definitely would like to support clone feature. I think we would work on this after upcoming API refactoring #170.

Thank you for initiating the discussion and feedback! 🙌

[mathetake]

Also, I haven't looked into JIT as... well, I'm on debian arm 😬

ps arm64 would be our next target in JIT so stay tuned! 😄

[mathetake]

Now that the instantiation cost is relatively cheap with the CompiledModule API, this problem this issue originally described is solved (previously store did compilation and installation all at once, and therefore the cost was large), also the context is outdated as our internals as well as APIs have been changed drastically.

[tonyhb]

Amazing, thank you @mathetake!