Stream: general

Topic: CoW for High Initialization Cost Modules


view this post on Zulip Friday More (Dec 17 2024 at 19:29):

Hello - my team is evaluating Wasmtime for a project and came across the PoolingAllocation / CoW features. We want to see if this can be helpful for our use case. We have a Wasm module with two exported functions. The first function is used for initial setup and is a very heavy operation which uses a large amount of memory. The second function is an extremely light operation which uses data structures set up by the first function (without modifying any of the data structures). We also want to prevent state accumulation in calls to the second function and plan to use this in a high QPS setting with multiple threads.

We currently have a proof of concept built with WAMR where we run the first function and then fork from that process to run the second function. This effectively achieves our use cases (run the heavy function once and reuse the data structures without paying the copying or memory cost because of CoW). Since it's a new fork each time, we are preventing state accumulation by resetting to a good state. The negative is the overhead of process cloning.

Wasmtime's PoolingAllocation / CoW seem like a great alternative to this. A few things that I am not very clear about:
Can I use Wasmtime to execute a heavy initialization function and then have that be the basis on which each new module instance is created when using Pooling Allocation with CoW? Does that kind of granular control exist?

Thank you so much!

view this post on Zulip Alex Crichton (Dec 17 2024 at 20:08):

Hello! Wasmtime's pooling allocator and CoW support is around accelerating and optimizing the instantiation of a wasm module, but this doesn't modify the lifetime of the instance itself and this support isn't related to, for example, taking a snapshot of a running instance and copying it.

That being said one architecture which might be able to work for you is to first run your module through wizer with the heavy function first. This produces a wasm file which is in effect a snapshot. Wasmtime can then efficiently run that second "wizened" file with the pooling allocator and CoW efficiently

The WebAssembly Pre-Initializer. Contribute to bytecodealliance/wizer development by creating an account on GitHub.

view this post on Zulip Friday More (Dec 17 2024 at 20:10):

That's really cool, I'll take a look at Wizer. Thank you!

view this post on Zulip Friday More (Dec 17 2024 at 21:27):

This may be a question for another group, but does Wizer allow input args for initialization (e.g. if I need a block of memory used in initialization)? Or do I need to enable Wasi and have the initialization method fetch it?

view this post on Zulip Alex Crichton (Dec 17 2024 at 21:34):

@fitzgen (he/him) might be able to help with the particulars of wizer (it should be possible one way or another though)

view this post on Zulip fitzgen (he/him) (Dec 17 2024 at 21:40):

On phone but while the initialization function’s signature is fixed you can provide WASI access and read from disk or env vars or you can even provide a custom linker and define your own import functions that are available at init time

view this post on Zulip Friday More (Dec 17 2024 at 22:06):

Thank you


Last updated: Dec 23 2024 at 12:05 UTC