Changes in instance.rs

439de7fb - Handle OOM in the rest of Wasmtime's non-component, -async, -compilation APIs (#12858)

Mon, 30 Mar 2026 18:35:31 +0000

Handle OOM in the rest of Wasmtime's non-component, -async, -compilation APIs (#12858)* Handle OOM in more places in the public APIA bunch of random places:* Add: `Trap::try_new` to handle OOM while creating traps* Use: `TryVec` inside `Func::call_impl_do_call` and `wasm_val_raw_storage` to hold the args and rets* Add: `Instance::try_exports` for iterating over an instance's exports while handling OOM* `Linker:try_get`, like `Linker::get` but handling OOM* `Linker:try_get_by_import`, like `Linker::get_by_import` but handling OOM* Use `try_new` to box things in `SharedMemory::new`* Use `TryVec` instead of `Vec` in our dynamic tables* Add OOM tests for most of Wasmtime's public APIExcludes component-, async-, and compilation-related APIs.* address review feedback* fix test compilation* fix c-api List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

282a1814 - Use `TryPrimaryMap` in an instance's `OwnedImports` (#12847)

Thu, 26 Mar 2026 17:45:48 +0000

Use `TryPrimaryMap` in an instance's `OwnedImports` (#12847) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

66ef086d - Use `TryVec` in the store's `FuncRefs` structure (#12845)

Thu, 26 Mar 2026 14:27:05 +0000

Use `TryVec` in the store's `FuncRefs` structure (#12845) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

183891f0 - Rename our OOM-handling `Vec` to `TryVec` (#12721)

Thu, 05 Mar 2026 00:03:12 +0000

Rename our OOM-handling `Vec` to `TryVec` (#12721)* Rename our OOM-handling `Vec` to `TryVec`* fix tests that got mangled by the LSP server* fix more tests mangled by LSP List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

0f280583 - Handle OOM in `Linker::instantiate_pre` (#12683)

Thu, 26 Feb 2026 23:40:29 +0000

Handle OOM in `Linker::instantiate_pre` (#12683) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

b90b8965 - Debugging: apply single-stepping patches to modules instantiated after setting changes. (#12663)

Wed, 25 Feb 2026 00:01:48 +0000

Debugging: apply single-stepping patches to modules instantiated after setting changes. (#12663)We currently do a store-wide state-change on all registered moduleswhen the "single stepping" flag changes, patching in or out allbreakpoints. However, this design didn't account for modulesregistered with the store *after* single-stepping is enabled (and newmodules may be registered any time an instantiation occurs). Inparticular this is problematic when a debugger, e.g., sets thesingle-step flag right at the beginning of execution of a "host mainfunction" that calls Wasm, before the main instantiation occurs.This PR threads through the breakpoint state in the registration path,with the narrow waist at `ModuleRegistry::register` which is the onlyplace where modules are added to the `LoadedCode`. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

7051ab30 - Debugging: add unique-within-store IDs for every entity. (#12645)

Tue, 24 Feb 2026 18:07:42 +0000

Debugging: add unique-within-store IDs for every entity. (#12645)When building an introspection API for use by a debugger, we need away to expose *identity*: that is, to give some way of knowing that agiven `Memory`, `Instance`, etc. is *this* one and not *that* one. Ourhandle types variously have either `Eq` implementations ore.g. `Module::same` for the ones that wrap an `Arc` under-the-covers;but that's not enough to allow a debugger to e.g. build a hashmap forwhatever metadata that it might expose via whatever debuggingprotocol.For maximal generality and flexibility, we should expose the uniqueIDs that already more-or-less exist: for instances, that is theirinstance ID directly; for entities owned by instances, we can build a`u64` with the instance ID in the upper 32 bits and the defined-indexin the lower 32 bits. IDs for all entities except modules areunique-within-a-Store (and this is all that is needed); IDs formodules happen to reuse the `CompiledModuleId` and so areunique-within-an-Engine.I've opted to name these `debug_index_within_store` to scope thefeature and intended use-case clearly, but if there's a desire, Icould easily rename them to simply `index`. I shied away from thathere because I didn't want to give a notion that these indices aresomehow canonical or correspond to some order or other. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

1f16b28f - Refactor `String` usage in `wasmtime_environ::Module` (#12565)

Thu, 12 Feb 2026 21:27:05 +0000

Refactor `String` usage in `wasmtime_environ::Module` (#12565)* Refactor `String` usage in `wasmtime_environ::Module`Do not hold regular `String`s; instead use our own OOM-handling`wasmtime_core::alloc::String` or, even better, an interned `Atom` from the`StringPool`.Also avoid `IndexMap`, as it doesn't handle OOMs.* Use OOM-handling `IndexMap` in `wasmtime_environ::Module`* review feedback List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.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/instance.rs

cc8d04f4 - Remove need for explicit `Config::async_support` knob (#12371)

Fri, 23 Jan 2026 02:46:45 +0000

Remove need for explicit `Config::async_support` knob (#12371)* Refactor component model host function definitionsPush the `async`-ness down one layer.* Remove need for explicit `Config::async_support` knobThis commit is an attempt to step towards reconciling "old async" and"new async" in Wasmtime. The old async style is the original asyncsupport in Wasmtime with `call_async`, `func_wrap_async`, etc, where themain property is that the store is "locked" during an async operation.Put another way, a store can only execute at most one async operation ata time. This is in contrast to "new async" support in Wasmtime with thecomponent-model-async (WASIp3) support, where stores can have more thanone async operation in flight at once.This commit does not fully reconcile these differences, but it doesremove one hurdle along the way: `Config::async_support`. Since thebeginning of Wasmtime this configuration knob has existed to explicitlydemarcate a config/engine/store as "this thing requires `async` stuffinternally." This has started to make less and less sense over timewhere the line between sync and async has become more murky with WASIp3where the two worlds comingle. The goal of this commit is to deprecate`Config::async_support` and make the function not actually do anything.In isolation this can't simply be done, however, because there are manyload-bearing aspects of Wasmtime that rely on this `async_support` knob.For example once epochs + yielding are enabled it's required that allWasm is executed on a fiber lest it hit an epoch and not know how toyield. That means that this commit is not a simple removal of`async_support` but instead a refactoring/rearchitecting of how async isused internally within Wasmtime. The high-level ideas within Wasmtimenow are:* A `Store` has a "requires async" boolean stored within it.* All configuration options which end up requiring async, such as yielding with epochs, turn this boolean on.* Creation of host functions which use async (e.g. `func_wrap_{async,concurrent}`) will also turn this option on.* Synchronous API entrypoints into Wasmtime ensure that this boolean is disabled.* Asynchronous APIs are usable at any time.This means that the concept of an async store vs a sync store is nowgone. All stores are equally capable of executing sync/async, and thechange now is that dynamically some stores will require that async isused with certain configuration. Additionally all panicking conditionsaround `async_support` have been converted to errors instead. Allrelevant APIs already returned an error and things are murky enough nowthat it's not necessarily trivial to get this right at the embedderlevel. In the interest of avoiding panics all detected async mismatchesare now first-class `wasmtime::Error` values.The end result of this commit is that `Config::async_support` is adeprecated `#[doc(hidden)]` function that does nothing. While manyinternal changes happened as well as having new tests for all this sortof behavior this is not expected to have a great impact on externalconsumers. In general a deletion of `async_support(true)` is in theoryall that's required. This is intended to make it easier to think aboutasync/sync/etc in the future with WASIp3 and eventually reconcile`func_wrap_async` and `func_wrap_concurrent` for example. That's leftfor future refactorings however.prtest:full* Review comments* Fix CI failures List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

af0ae833 - Reduce duplication amongst `debug_*` helpers (#12386)

Wed, 21 Jan 2026 22:10:44 +0000

Reduce duplication amongst `debug_*` helpers (#12386)Deduplicate the check for `guest_debug`, validity checks, and conversionfrom `Export` to `Extern`. No functional change here, just arefactoring. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

2326d655 - Debugging: provide access to private (non-exported) entities. (#12367)

Wed, 21 Jan 2026 17:00:31 +0000

Debugging: provide access to private (non-exported) entities. (#12367)* Debugging: provide access to private (non-exported) entities.A debugger will need to access all entities (globals, tables, memories),even those that are not exported, in order to provide a full debuggingexperience: for example, a developer who has a debugger attached to aWasm component will expect to be able to see data in its memory.Historically we have been very careful in Wasmtime to provide access toWasm instances' entities only as the Wasm type system allows -- that is,only if they are exported. However, debugging is privileged -- in thesame way that a native host debugger has `ptrace` and can vieweverything about the debuggee, we need to provide APIs for seeingthrough the encapsulation boundary.To ensure that this "violation of encapsulation" is scoped only to theextent needed for the legitimate need (debugging), this API isdynamically available only when `guest_debug` is configured true for agiven engine. Otherwise, the accessor returns `None`.I opted not to provide a full introspection API that enumerates all ofthe entities as the debugger should already have access to the debuggeemodule and be able to enumerate the entities. Thus, the API onlyprovides a host-API handle when asking for an entity by index in a giveninstance's index space.* Review feedback.* Fix tests on 32-bit build (where threads and thus shared memory are not supported) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

8c349a3d - Refactor core wasm host entrypoints (#12366)

Tue, 20 Jan 2026 20:40:02 +0000

Refactor core wasm host entrypoints (#12366)* Refactor core wasm host entrypointsThis commit refactors the internals of how guest functions call out tothe host. Previously Wasmtime had a split where `Func::new`-styleconstructors used one entrypoint and `Func::wrap`-style entrypoints useda different entrypoint. This was required long ago when we had an arrayand native ABI calling convention, but nowadays this is no longerrequired. This refactors things to have a single base-level signaturewhich is the narrow waist through which all other function entrypointsgo through. This enables having a single function handle all the thingslike panicking, call hooks, etc, and everything further builds on top ofit.This commit additionally pushes the async-ness of a function down evenfurther. Previously many `*_async` constructors would quickly delegateto their non-async counterpart, but this is expected to more-or-lessbecome not the right way to do things as wasmtime moves into thefuture. Historical refactorings related to GC, for example, have pushed`async` further down within Wasmtime and this continues that trend.There's no immediate benefit just yet, but this is hoped to make futurerefactorings easier.Along the way some minor API changes happened too:* `*_unchecked` constructors now work with `MaybeUninit` to correctly model how some values may not be initialized.* Some `*_async` functions picked up `T: Send` which should have in theory been required before and are now compiler-required.* Longstanding/old internal functions have been shuffled around/refactored.Finally, another eventual goal of this work is to share more betweencore wasm and components in terms of implementation. Right now thecomponent host function entrypoints are quite different than the corewasm ones and that ideally wouldn't endure forever.* Fix c-api build* Fix dead code* Fix benchmarks build* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

ff33e949 - Do not re-export `anyhow!` in the `wasmtime::prelude` (#12298)

Fri, 09 Jan 2026 19:23:56 +0000

Do not re-export `anyhow!` in the `wasmtime::prelude` (#12298)We are trying to move to `format_err!` instead. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

23b2fe3f - Debugging: allow frame cursor to visit all activations. (#12176)

Wed, 17 Dec 2025 21:39:11 +0000

Debugging: allow frame cursor to visit all activations. (#12176)* Debugging: allow frame cursor to visit all activations.In the initial design for the `DebugFrameCursor`, I was concernedabout the effects of host async on the stability of visiting earlieractivations (see also the discussion of async combinators in #11896).The basic hypothesized problem was that when Wasm calls host-codecalls Wasm, the sequence of activations on the stack is not evenstable between async polls; so any debugger hook, which is an asyncfunction, should not be allowed to hold a frame cursor across a yieldpoint since it could become invalidated if the next poll stacks up theactivations differently.In further conversations it's become clear that this is not actually apossibility, for the simple reason that the inner re-entrantactivations into the same store take full ownership (mutably reborrow)that store, and that mut reborrow becomes part of the future; so theexact chain of activations will remain in the same sequence whenre-polled. Said another way, it is impossible at any given level ofasync host-code to create *more than one* future that re-enters thesame store and somehow poll those in different orders at differenttimes. The worst that a host-code async combinator can do is drop thefuture that re-enters the store. This drops and invalidates whateverframes a cursor held over a yield might be referencing, but it *also*drops the async invocation of the debugger hook itself, and due tolifetimes the cursor cannot escape that hook, so everything is stillsound.This PR thus updates the `DebugFrameCursor` to visit allactivations. I've generalized the backtrace code a bit to enable this,and built an internal `StoreBacktrace` that is an iterator over allactivations associated with the store.At the `DebugFrameCursor` (public API) level, the two basic choiceswere to present a sentinel for host frame(s) explicitly and make allWasm-specific accessors return `Option`, or skip over hostframes. I opted for the latter, with `move_to_parent()` returning anenum value now that indicates whether it moved to a new activation.A note regarding the *async* component ABI: once debugging is possiblewithin a `run_concurrent` environment, it will again be the case thata single frame cursor should see only one activation, becauseeach (re)-entry into the store becomes a new task, if my understandingis correct. At that time, we should build an API that lets thedebugger see the activation for each task separately. That's a simplermodel ultimately, and it will be nice when we move to it, but as longas we have the sync component ABI with async host code and the abilityto stack activations as we do today, we need to provide the debuggerthis visibility.(Aside: why does the debugger *need* to see more than one activation?In addition to presenting a weird and incoherent view of the world tothe user if we don't, it is also necessary to implement the"next" (step-over) debugger action, because otherwise a call to a hostfunction that re-enters the store may lead to a state with fewer, butcompletely disjoint, stack frames on the "one latest activation" fromwhich it's not possible to reason about whether we've left thecalled-into function yet.)* Review feedback.* cargo fmt. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.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/instance.rs

1fcd0933 - Prevent using shared memories with `Memory` (#12022)

Tue, 11 Nov 2025 18:06:22 +0000

Prevent using shared memories with `Memory` (#12022)* Prevent using shared memories with `Memory`This commit fixes a few issues where it was possible to represent a wasmshared linear memory with the `wasmtime::Memory` type. This is not soundbecause `wasmtime::Memory` provides safe Rust access to the bytes wherethat is not possible with wasm shared memories. Shared memories in Rustmust be represented by `SharedMemory`, not `wasmtime::Memory`.Specifically this commit prevents two vectors of this happening:1. `Memory::new` now requires that the memory type specified is non-shared. Instead `SharedMemory::new` must be used instead.2. Core dumps now skip over shared memories when iterating over all memories in the store. Supporting shared memories is left to a future feature request for now.* CI fixes List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

557cc2d6 - Another batch of dependency updates (#11832)

Fri, 10 Oct 2025 17:12:23 +0000

Another batch of dependency updates (#11832)* Another batch of dependency updatesBringing some deps in `Cargo.toml` up-to-date with their latest versionsalong the same lines as #11820 to avoid deps getting too stale/old.Code-wise this updates `anyhow` which enables preexisting Clippywarnings to check more code, so those warnings are fixed here as well.prtest:full* Run rustfmt List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

155ea7fc - Remove unsoundness of widening store borrows (#11481)

Thu, 21 Aug 2025 01:24:33 +0000

Remove unsoundness of widening store borrows (#11481)* Remove unsoundness of widening store borrowsThis commit removes preexisting unsoundness in Wasmtime where a`&mut StoreOpaque` borrow was "widened" into encompassing the limiter onthe `T` in `StoreInner`, for example, by using the self-pointerlocated in an instance or the store. This fix is done by threading`&mut StoreOpaque` as a parameter separately from a`StoreResourceLimiter`. This means that various callers now take a new`Option<&mut StoreResourceLimiter<'_>>` parameter in various locations.Closes #11409* Fix gc-less build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs

e1f50aad - Make table/memory creation async functions (#11470)

Thu, 21 Aug 2025 00:02:31 +0000

Make table/memory creation async functions (#11470)* Make core instance allocation an `async` functionThis commit is a step in preparation for #11430, notably core instanceallocation, or `StoreOpaque::allocate_instance` is now an `async fn`.This function does not actually use the `async`-ness just yet so it's anoop from that point of view, but this propagates outwards to enoughlocations that I wanted to split this off to make future changes moredigestable.Notably some creation functions here such as making an `Instance`,`Table`, or `Memory` are refactored internally to use this new `async`function. Annotations of `assert_ready` or `one_poll` are used asappropriate as well.For reference this commit was benchmarked with our `instantiation.rs`benchmark in the pooling allocator and shows no changes relative to theoriginal baseline from before-`async`-PRs.* Make table/memory creation `async` functionsThis commit is a large-ish refactor which is made possible by the manyprevious refactorings to internals w.r.t. async-in-Wasmtime. The endgoal of this change is that table and memory allocation are both `async`functions. Achieving this, however, required some refactoring to enableit to work:* To work with `Send` neither function can close over `dyn VMStore`. This required changing their `Option<&mut dyn VMStore>` arugment to `Option<&mut StoreResourceLimiter<'_>>`* Somehow a `StoreResourceLimiter` needed to be acquired from an `InstanceAllocationRequest`. Previously the store was stored here as an unsafe raw pointer, but I've refactored this now so `InstanceAllocationRequest` directly stores `&StoreOpaque` and `Option<&mut StoreResourceLimiter>` meaning it's trivial to acquire them. This additionally means no more `unsafe` access of the store during instance allocation (yay!).* Now-redundant fields of `InstanceAllocationRequest` were removed since they can be safely inferred from `&StoreOpaque`. For example passing around `&Tunables` is now all gone.* Methods upwards from table/memory allocation to the `InstanceAllocator` trait needed to be made `async`. This includes new `#[async_trait]` methods for example.* `StoreOpaque::ensure_gc_store` is now an `async` function. This internally carries a new `unsafe` block carried over from before with the raw point passed around in `InstanceAllocationRequest`. A future PR will delete this `unsafe` block, it's just temporary.I attempted a few times to split this PR up into separate commits buteverything is relatively intertwined here so this is the smallest"atomic" unit I could manage to land these changes and refactorings.* Shuffle `async-trait` dep* Fix configured build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/instance.rs