Expose memory `needs_init` on `LinearMemory`/`RuntimeLinearMemory`

[d-sonuga]

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.

[alexcrichton]

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?

[d-sonuga]

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?

[alexcrichton]

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