Stream: git-wasmtime

Topic: wasmtime / issue #12517 Expose memory `needs_init` on `Li...

Wasmtime GitHub notifications bot (Feb 04 2026 at 16:25):

d-sonuga opened issue #12517:

Feature

Need to have control over whether or not a linear memory is reinitialized when a module is instantiated.

Benefit

The use-case for this is to have persistent memory that does not get wiped out across runs.

Implementation

Expose a needs_init function on the LinearMemory trait. It can default to true, which will resort to the
current behavior of always reinitializing the memory when a module is instantiated.

Wasmtime GitHub notifications bot (Feb 05 2026 at 18:33):

alexcrichton commented on issue #12517:

The intention of custom linear memories is to enable customization of how it's allocated while still enforcing WebAssembly's semantics. Given that I don't think we'll expose a knob like this if it enables subverting WebAssembly's semantics or breaking the encapsulation of modules. Instantiating a WebAssembly module, for example, is a well-defined operation in terms of how exactly a memory should appear after instantiation.

Can you elaborate more on your use case and how you want to use this? For example what is the shape of the module that you are instantiating? How are you looking to reuse data between instantiations?

Wasmtime GitHub notifications bot (Feb 06 2026 at 10:59):

d-sonuga commented on issue #12517:

The use case is there are webassembly modules whose memories represent state that must not be reset. So, whenever some wasm operation mutates that state, say some static variable is set to some new value, it must stay the same across runs.
Effectively, it's a resume VM thing, where conceptually, it should be like execution never ended.

As for the shape, each module has its own exported memory, defined in the module, with data segments intended to be applied once, no shared memory between modules and no concurrent instances alive at the same time.

Currently, we have our own fork of Wasmtime that adds this needs_init to the memory so that it does not get re-initialized on every instantiation, to get it to behave like a reattachment to existing state, not as a reset.

I guess, in light of the wasm spec thing, this is sort of a hack. I'd be very interested in your perspective on whether there's a more spec-aligned way of doing this?

Wasmtime GitHub notifications bot (Feb 06 2026 at 17:41):

alexcrichton commented on issue #12517:

One possibility, which is similar to how threads originally worked, is to import a memory instead of exporting a memory. The module would then expose an initialization function for applying the data segments the first time, and the engine would then orchestrate calling that once but not for future runs.

Alternatively you could post-process wasm modules to do this sort of manually. For example you could rewrite a memory-export-with-data-segments to a memory-import-with-initialization-function. You may wish to do this sort of post-processing to export other state from the module, such as globals/tables, too

Last updated: Feb 24 2026 at 04:36 UTC