Changes in data.rs

7e11f182 - Consolidate component-related store data (#12549)

Mon, 09 Feb 2026 21:02:06 +0000

Consolidate component-related store data (#12549)Instead of having `#[cfg]` within `store.rs` move it all to`component/store.rs` to cut down on `#[cfg]`. It's a bit awkward in someplaces trying to borrow a bunch of fields at once, but it's not the endof the world. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

99ecf728 - Debug: create private code memories per store when debugging is enabled. (#12051)

Wed, 03 Dec 2025 01:18:00 +0000

Debug: create private code memories per store when debugging is enabled. (#12051)* Debug: create private code memories per store when debugging is enabled.This will allow patching code to implement e.g. breakpoints. (That is,for now the copies are redundant, but soon they will not be.)This change follows the discussion [here] and offline to define a fewtypes that better encapsulate the distinction we want to enforce.Basically, there is almost never a bare `CodeMemory`; they are alwayswrapped in an `EngineCode` or `StoreCode`, the latter being a per-storeinstance of the former. Accessors are moved to the relevant place sothat, for example, one cannot get a pointer to a Wasm function's bodywithout being in the context of a `Store` where the containing modulehas been registered. The registry then returns a `ModuleWithCode` thatboxes up a `Module` reference and `StoreCode` together for cases wherewe need both the metadata from the module and the raw code to derivesomething.The only case where we return raw code pointers to the `EngineCode`directly have to do with Wasm-to-array trampolines: in some cases, e.g.`InstancePre` pre-creating data structures with references to hostfunctions, it breaks our expected performance characteristics to makethe function pointers store-specific. This is fine as long as theWasm-to-array trampolines never bake in direct calls to Wasm functions;the strong invariant is that Wasm functions never execute from`EngineCode` directly. Some parts of the component runtime would alsohave to be substantially refactored if we wanted to do away with thisexception.The per-`Store` module registry is substantially refactored in this PR.I got rid of the modules-without-code distinction (the case where amodule only has trampolines and no defined functions still works fine),and organized the BTreeMaps to key on start address rather than endaddress, which I find a little more intuitive (one then queries with thedual to the range -- 0-up-to-PC and last entry found).[here]: https://github.com/bytecodealliance/wasmtime/pull/12051#pullrequestreview-3493711812* Review feedback: do not assume a reasonable code alignment; error when it cannot be known* Review feedback: fail properly in profiler when we are cloning code* Fix guest-profiler C API.* Review feedback: make private-code representation impossible in non-debugging-support builds.* Add TODO comment referencing issue for cloning only .text.* clang-format* Review feedback: add back Component::image_range.* Review feedback: error on registering profiling metadata when debug is enabled.* rustfmt* Remove early bail on profiling-data registration when debugging is enabled: this always happens so we cannot error out. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

5f7cf53e - Make table growth a true `async fn` (#11442)

Mon, 18 Aug 2025 18:03:38 +0000

Make table growth a true `async fn` (#11442)* Make table growth a true `async fn`Upon further refactoring and thinking about #11430 I've realized that wemight be able to sidestep `T: Send` on the store entirely which would bequite the boon if it can be pulled off. The realization I had is thatthe main reason for this was `&mut dyn VMStore` on the stack, but thatitself is actually a bug in Wasmtime (#11178) and shouldn't be done.The functions which have this on the stack should actually ONLY have theresource limiter, if configured. This means that while the`ResourceLimiter{,Async}` traits need a `Send` supertrait that'srelatively easy to add without much impact. My hunch is that plumbingthis through to the end will enable all the benefits of #11430 withoutrequiring adding `T: Send` to the store.This commit starts out on this journey by making table growth a true`async fn`. A new internal type is added to represent a store's limiterwhich is plumbed to growth functions. This represents a hierarchy ofborrows that look like:* `StoreInner` * `StoreResourceLimiter<'_>` * `StoreOpaque` * `Pin<&mut Instance>` * `&mut vm::Table`This notably, safely, allows operating on `vm::Table` with a`StoreResourceLimiter` at the same time. This is exactly what's neededand prevents needing to have `&mut dyn VMStore`, the previous argument,on the stack.This refactoring cleans up `unsafe` blocks in table growth rightnow which manually uses raw pointers to work around the borrow checker.No more now!I'll note as well that this is just an incremental step. What I plan ondoing next is handling other locations like memory growth, memoryallocation, and table allocation. Each of those will require furtherrefactorings to ensure that things like GC are correctly accounted forso they're going to be split into separate PRs. Functionally though thisPR should have no impact other than a fiber is no longer required for`Table::grow_async`.* Remove #[cfg] gate List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

4b518271 - Add `#[inline]` to some small functions (#11235)

Mon, 14 Jul 2025 16:21:58 +0000

Add `#[inline]` to some small functions (#11235)This adds `#[inline]` to some functions which are otherwise notavailable for cross-crate inlining. These functions started being moreheavily used after historical refactorings such as #10877 so this helpsbenchmarks which access linear memory in host functions, for example. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

aad93a48 - Crack down on mutability and ownership of `vm::Instance` (#10943)

Fri, 06 Jun 2025 15:59:57 +0000

Crack down on mutability and ownership of `vm::Instance` (#10943)* Crack down on mutability and ownership of `vm::Instance`This commit represents more effort to bring safety to `vm::Instance`and, eventually, `ComponentInstance`. This is specifically addressingtwo points of safety around `vm::Instance`:* Previously ownership of this was murky where `InstanceHandle` sort of represented ownership but sort of didn't either through the `InstanceHandle::clone` method. Now `InstanceHandle` has a destructor for instances and no longer has `clone`, so there's one exclusive owner of an instance.* Previously `&mut Instance` was liberally passed around, but this is not sound because certain fields cannot be mutated (e.g. runtime offset information). While not a perfect solution this PR switches to using `Pin<&mut Instance>` everywhere instead. This prevents safe access to `&mut Instance` and we hand-write accessors to individual fields. Notably we omit mutable access to the `runtime_info` field.This naturally involved a lot of refactoring internally, but notablythis started bringing up preexisting issues around how there arelocations in the codebase that simultaneously have `&mut Instance` and`&mut StoreOpaque` which is technically not sound due to being able toget back to the instance from the store. Some issues here were addressby passing around indices more often such as in instance initializationand const-expr evaluation.Note that all proxy methods on `InstanceHandle` are also all removed nowand there's now only two: `get` and `get_mut`. This reflects how`InstanceHandle` should in general no longer be used and instead`Instance` itself, and some pointer-to thereof, should be exclusivelyused.cc #10933* Fix stack-switching-less build* Fix wmemcheck build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

47e90882 - Start reducing unsafety of `ComponentInstance` (#10934)

Thu, 05 Jun 2025 21:44:02 +0000

Start reducing unsafety of `ComponentInstance` (#10934)Work recently in the wasip3-prototyping repository has focused onreducing the amount of `unsafe` code and improving internal abstractionsto facilitate this. One major thrust that's manifested in is the removalof the usage of `*mut ComponentInstance` where possible and insteadusing an index to safely borrow from the store to get the entireinstance. This commit does not fully realize this vision just yet butlays some groundwork leading up to this.This commit specifically removes the `*mut ComponentInstance` pointersin lift/lower contexts in favor of directly storing a`wasmtime::component::Instance`. When the raw `ComponentInstance` isneeded it's acquired from the `StoreOpaque` in a safe fashion thatborrows the entire store for the duration of the returned borrow. Thisin turn required pushing instances into the store earlier duringinstantiation because during instantiation an instance could call out tohost APIs which do lifts/lowers.There's still more work to be done to plumb this fully into libcalls andhost function invocations but I wanted to upstream the wasip3 workpiecemeal a chunk at a time. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

5603ee7b - Change component/instance maps to `PrimaryMap` (#10916)

Tue, 03 Jun 2025 22:11:29 +0000

Change component/instance maps to `PrimaryMap` (#10916)* Change component/instance maps to `PrimaryMap`This switches to using typed keys for these maps to be more idiomaticwith the rest of Wasmtime and this has the additional benefit ofcompressing indices to 32-bits instead of the previouspointer-sized-bits.* Fix an unused import List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

ff393fbc - Remove `Stored` (#10917)

Tue, 03 Jun 2025 22:05:02 +0000

Remove `Stored` (#10917)Prior refactorings have removed the need for this abstraction, so deleteit entirely (yay!). List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

e012eeda - Remove Stored from wasmtime::Instance (#10909)

Tue, 03 Jun 2025 14:59:25 +0000

Remove Stored from wasmtime::Instance (#10909)* Remove the "export cache" on instancesThis is now a relic of the past now that conversion from the internalto external representation of Wasmtime items is free. This iseffectively dead code that is no longer needed.* Remove `Stored` from `wasmtime::Instance`Powered by all previous commits this is a near-trivial change where an`Instance` is now more-or-less "just" an `InstanceId`. Additionally the`host_state: Box` is no longer needed within `vm::Instance` sothat was removed as well. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

a30e7299 - Update the definition of `wasmtime::Table` (#10903)

Tue, 03 Jun 2025 05:04:01 +0000

Update the definition of `wasmtime::Table` (#10903)This commit is similar to a prior commit modifying memories whichrefactors the internals of `wasmtime::Table` to not longer use a`Stored` index. Instead a `StoreInstanceId` and a `DefinedTableIndex` isused instead. This enables construction of external-facing types to betrivial and zero-cost.This additionally notably fixes an issue where triggering a GC in astore would unconditionally create a `Table`, pushing onto an internalvector in the store. This then would never be deallocated because theinternal table lived as long as the `Store`. In effect this meant thattriggering a GC would end up leaking memory by pushing more items ontointernal `Store` table. This is fixed through this commit becausecreating a `wasmtime::Table` is now "free" and no longer requires anyallocations. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

4fcfe17a - Refactor the representation of `Func` (#10897)

Mon, 02 Jun 2025 23:55:52 +0000

Refactor the representation of `Func` (#10897)* Refactor the representation of `Func`This commit rewrites the internals of `wasmtime::Func`. The `Stored`type is no longer used meaning that it's now free to create a`wasmtime::Func` at any time. It is effectively a store-tagged`NonNull`. This required a few internal changes to howfunctions are passed around:* Previously the insertion of a `wasm_call`-less `VMFuncRef` was deferred until the raw pointer was loaded. Now the insertion happens immediately as soon as the function is placed within a store. This is done to ensure that a `Func` corresponds to one exact `VMFuncRef` and that's it, and lazily filled in versions within the store are still lazily filled in but they're more eagerly allocated. This isn't expected to have much of an impact perf-wise since all these lazily allocated functions were already almost guaranteed to get lazily allocated anyway.* Filling in "holes" in `VMFuncRef`, notably the `wasm_call` field, no longer happens lazily when the `VMFuncRef` is demanded. Instead during instantiation a pass is made to fill in holes with the new module being instantiated (after registration). Additionally when a lazily-allocated `VMFuncRef` is created the module registry is checked immediately. This means that all store-local `VMFuncRef` values are either filled in immediately or filled in during instantiation. This notably means that the previous logic in `Func::vmimport` is now "just" an `.unwrap()` with a lot of comments saying why the unwrap shouldn't panic.* To implement this commit a previous optimization for the `Func` API was removed as well, namely `Func::call` will become slower after this commit. The `Func::call` API is a dynamically-typed API which requires run-time type-checking of arguments. Previously a `FuncType` was loaded into a cache once-per-`Func` which helped amortize the cost of using `Func::call` repeatedly. Now, though, there's no natural place to put such a cache since `Func` no longer has dedicated storage within a `Store`. Historically this optimization was added for the C API before the `*_call_unchecked` APIs existed, but nowadays the `*_call_unchecked` APIs should suffice for performance-critical applications where needed. In the future it might also be possible to have a hash map in the `Store` of a `VMSharedTypeIndex` to `FuncType` which is lazily populated based on calls to `Func::call`, but that feels a bit overkill nowadays for a possibly rarely-used map.* The no-longer-necessary `RootedHostFunc` type is now gone as its unsafety and various contracts are subsumed by other preexisting `unsafe` blocks.* The specific drop order between `StoreOpaque::store_data` and `StoreOpaque::rooted_host_funcs` is removed. The `rooted_host_funcs` field now lives in the `func_refs` field and the `FuncKind` type, where the destructors came from before, is no more.* The `func_refs` field has grown storage locations for a variety of "keep this thing alive as long as the store" related to functions and such.Closes #10868* Remove mutability from locations that no longer need it* Update crates/wasmtime/src/runtime/func.rsCo-authored-by: Nick Fitzgerald * Update crates/wasmtime/src/runtime/store/func_refs.rsCo-authored-by: Nick Fitzgerald ---------Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

c4fd2f7b - Refactor globals to no longer use `Stored` (#10902)

Mon, 02 Jun 2025 23:23:47 +0000

Refactor globals to no longer use `Stored` (#10902)This commit refactors the `wasmtime::Global` to avoid the usage of`Stored` internally. This makes conversion from internal global stateto external global state a noop along the lines of previous commits. Theend goal is to remove `Stored` entirely and enable more pervasively usingexternal types internally within Wasmtime as well.Globals were different than the prior iterations of memories, tags, andtables. Globals have three different ways of defining them: wasminstances, the host embedder, and component flags. Representing thesein all the various locations required a bit of finesse in how everythingis represented and stored at rest and such. In the end there's a smallamount of "type punning" in a few instance/vmctx fields related toglobals now since everything is squeezed into one slot. This is requiredbecause the `VMGlobalImport` structure must have a size known towasm-compiled code and `wasmtime::Global` must have a known layout for Ccode.In the end while this is more code to manage globals my hope is that theend result will be a net negative in terms of complexity by ensuringthat the embedder API is additionally suitable for use internally withinWasmtime as well. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

d6265b21 - Refactor `wasmtime::Tag`'s representation (#10901)

Mon, 02 Jun 2025 21:26:18 +0000

Refactor `wasmtime::Tag`'s representation (#10901)Removes the use of `Stored` to ensure that creating an external `Tag` isa free operation with just some indices into store-internal data. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

00eb216a - Add a new `ComponentInstanceId` type (#10896)

Mon, 02 Jun 2025 18:52:38 +0000

Add a new `ComponentInstanceId` type (#10896)This is intended to be similar to `InstanceId`, but used for components. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

0e9a691d - Update the definition of `wasmtime::Memory` (#10877)

Fri, 30 May 2025 22:34:21 +0000

Update the definition of `wasmtime::Memory` (#10877)Powered by the previous commit this change updates the internalimplementation details of `wasmtime::Memory` to avoid the need for theuse of `Stored`. This means that converting from a Wasmtime-internalrepresentation of a memory to an external representation of a memory islargely a noop and no longer requires an allocation. This is intended tobe more useful in the future to use the public types more pervasivelyinside of Wasmtime itself, but for now this is mostly the scaffoldingnecessary for such a change. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

ed20d93d - Store an `InstanceId` in `vm::Instance` (#10872)

Fri, 30 May 2025 21:16:31 +0000

Store an `InstanceId` in `vm::Instance` (#10872)* Store an `InstanceId` in `vm::Instance`This commit is the beginning of an effort to clean up `unsafe`-relatedcode about how we manage instances in the guts of Wasmtime. This doesn'thave any affect on the public API but it's will result eventually inchanges to the internals of types in the public API. This change is alsodone in preparation for simplifying `Stored` and how it works inWasmtime to avoid requiring allocations (aka pushing onto a `StoreData`vector) when converting from Wasmtime's internal representation to theexternal representation of tables, globals, memories, etc.For now all this commit does is add `id: InstanceId` to the`vm::Instance` structure. This led to some refactorings to ensure thatit's correctly listed by centralizing various methods to allocate aninstance into one helper method which manages this configuration.* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

c22b3cb9 - Reuse Wasm linear memories code for GC heaps (#10503)

Fri, 11 Apr 2025 21:15:55 +0000

Reuse Wasm linear memories code for GC heaps (#10503)* Reuse code for Wasm linear memories for GC heapsInstead of bespoke code paths and structures for Wasm GC, this commit makes itso that we now reuse VM structures like `VMMemoryDefinition` and bounds-checkinglogic. Notably, we also reuse all the associated bounds-checking optimizationsand, when possible, virtual-memory techniques to completely elide them.Furthermore, this commit adds support for growing GC heaps, reusing themachinery for growing memories, and makes it so that GC heaps always start outempty. This allows us to properly delay allocating the GC heap's storage until aGC object is actually allocated.Fixes #9350* fix c api compilation* use assert_contains* remove no-longer-necessary extra memory config from limiter tests* Helper for retry-after-maybe-async-gc in libcalls* Clean up some comments* fix wasmtime-fuzzing and no-gc compilation* fix examples* fix no-gc+compiler build* fix build without pooling allocator* fix +cranelift +gc-drc -gc-null builds* fix table hash key stability test* fix oracle usage of `ExternRef::new`* fix +gc -gc-null -gc-drc build* fix wasmtime-fuzzing* make `StorePtr` wrap a `NonNull`* Fix some doc tests* Remove some unnecessary retry helpers now that `FooRef::new` will auto-gc* fix things after rebase* Reorganize collection/growth methods for GC heap* rename BoundsCheck variants* fix cfg'ing of gc only code* Fix doc tests* fix one more gc cfg* disable GC heap OOM test on non-64-bit targets List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

0b4c754a - Exception and control tags (#10251)

Thu, 20 Feb 2025 15:49:20 +0000

Exception and control tags (#10251)* Tags* Tag tests* Tests* Refer to tags issue* Engine index* Simplify* Fix clippy warnings List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

10eda1cf - Support platforms without 64-bit atomics (#10134)

Wed, 29 Jan 2025 15:53:25 +0000

Support platforms without 64-bit atomics (#10134)* Support platforms without 64-bit atomicsThis commit enables Wasmtime to build on platforms without 64-bit atomicinstructions, such as Rust's `riscv32imac-unknown-none-elf` target.There are only two users of 64-bit atomics right now which are epochsand allocation of `StoreId`. This commit adds `#[cfg]` to epoch-relatedinfrastructure in the runtime to turn that all of if 64-bit atomicsaren't available. The thinking is that epochs more-or-less don't workwithout 64-bit atomics so it's easier to just remove them entirely.Allocation of `StoreId` is trickier though because it's so core toWasmtime and it basically can't be removed. I've opted to change theallocator to 32-bit indices instead of 64-bit indices. Note that`StoreId` requires unique IDs to be allocated for safety which meansthat while a 64-bit integer won't overflow for a few thousand years a32-bit integer will overflow in a few hours from quickly creatingstores. The rough hope though is that embeddings on platforms like thisaren't churning through stores. Regardless if this condition istriggered it'll result in a panic rather than unsoundness, so wehopefully have at least that going for us.Closes #8768* Update component resources to not use `AtomicU64`These aren't intended to be used in threaded contexts anyway and the useof `AtomicXXX` is just to have interior mutability while still being`Send` and `Sync`. Switch to using `AtomicU32` which is more portable.* Use `RwLock` for `StoreId` instead.* Fix compile* Fix imports List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs

de1ad347 - Enable `impl-trait-overcaptures` 2024 transition lint (#9965)

Thu, 09 Jan 2025 23:13:22 +0000

Enable `impl-trait-overcaptures` 2024 transition lint (#9965)* Enable `impl-trait-overcaptures` 2024 transition lintThis lint detects cases where returning `impl Trait` will workdifferently in 2024 than in the current 2021 edition. Ambiguities areresolved with `use<..>` syntax stabilized in Rust 1.82.0 to mean thesame thing in both editions.* Fix some more `impl Trait` returns* Tighten bounds on settings `iter`* Fix build on 1.82.0* Fix another capture on MSRV List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/store/data.rs