Antoine Lavandier (Feb 18 2026 at 16:09): Antoine Lavandier (Feb 18 2026 at 16:09):Is there a way to reclaim the linear memory used by an Instance (Component or Module) without destroying the Store ?
The use case is a service where people can publish, update and run wasm code running on micro controllers. Right now all of the instances belong to the same store so if I update the same capsule over and over (destroying the instance and rebuilding it) at some point since the store is never destroyed wasmtime panics (in my testing at `src/runtime/vm/mmap_vec.rs:72:18).
Is there a way to:
MmapVec::new_externally_owned/Mmap::from_raw seem like they could be part of the solution. Is there an example of usage somewhere that I could take inspiration from ? Wasmtime version is 42.0 at rev 3dc6b5ec5572ab8b304c668d5b929bbc7f49cbcf
Chris Fallin (Feb 18 2026 at 16:28):No, the Store is meant to be cheap to create and freshly created for each unit of work you have -- "request", or an update lifecycle, or whatever. Unfortunately there's no way to remove an instance from a store once created (doing so would greatly complicate our index-based handles; we'd need some kind of invalidation and/or GC)
Chris Fallin (Feb 18 2026 at 16:29):in your host code, is there a reason you can't create a new store each time you "destroy the instance and rebuild it"?
Antoine Lavandier (Feb 18 2026 at 16:40):Right now I could do as you say (and will if it's the only option) but I have concerns: currently I have one store that "owns" all of my instances, to do what you propose, I would need to either have a) one store per instance or b) kill all of the instances, destroy the store, update the relevant bytecode, rebuild everything everytime I want to update the capsules.
a) has the following issues :
b) seems generally like a hassle and inefficient
fitzgen (he/him) (Feb 18 2026 at 17:09):Store is designed to be cheap to create and throw away, that is its main use case
fitzgen (he/him) (Feb 18 2026 at 17:10):e.g. function-as-a-service platforms create one Store (and Instance within that store) per incoming HTTP request, and then throw it away when the HTTP request is completed; create a new Store for the next incoming HTTP request, etc...
Chris Fallin (Feb 18 2026 at 17:11):What if my store data is non trivial and thus cloning isn't great
If there's shared data you need to reference from hostcalls on all stores, you could put it behind an Arc and share a reference to it? That's cheap to clone
If at some point I want to support composing the modules/components then I run into an issue because I would need several instances on a single store.
This one is interesting; having instances with different lifetimes in different stores talk to each other somehow is a plausible use-case. You can make this work with some host-side glue (an instance/function handle API basically)
Till Schneidereit (Feb 18 2026 at 23:12):FWIW instances with different lifetimes are currently somewhat fundamentally not supported for composed components: there's no way to sever the link between one component's exports and another's imports, for one. The Component Model change intended to make this viable is described here. Implementing this will certainly involve either a pretty substantial change in Wasmtime's architecture or (much more likely) using separate stores per "blast zone"
Antoine Lavandier (Feb 19 2026 at 10:33):Thanks for the replies. I think that for now I'll just have multiple stores and deal with code composition when it becomes relevant.
Also, is there a way or a plan to make the panic go away ? I would prefer my service to reply with a non enough memory error than straight up crash ...
Alex Crichton (Feb 19 2026 at 15:43):I've sent https://github.com/bytecodealliance/wasmtime/pull/12625 to handle the panic by returning an error instead
Last updated: Feb 24 2026 at 04:36 UTC