Changes in instance.rs

9c44a9b4 - Use `TryPrimaryMap` in `Instance` (#12848)

Thu, 26 Mar 2026 18:26:52 +0000

Use `TryPrimaryMap` in `Instance` (#12848) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance.rs

ab78bd82 - fix: correct various typos (#12807)

Sun, 22 Mar 2026 18:10:20 +0000

fix: correct various typos (#12807)Signed-off-by: Ho Kim List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance.rs

1c1843da - Rename our OOM-handling `EntitySet` to `TryEntitySet` (#12722)

Thu, 05 Mar 2026 01:14:02 +0000

Rename our OOM-handling `EntitySet` to `TryEntitySet` (#12722) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance.rs

e9a6def7 - Remove unused `wasmtime::runtime::vm::Instance::exports` method (#12579)

Thu, 12 Feb 2026 20:01:08 +0000

Remove unused `wasmtime::runtime::vm::Instance::exports` method (#12579) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance.rs

a465eabf - Introduce `wasmtime::Store::try_new`, which handles OOM (#12415)

Tue, 27 Jan 2026 00:13:33 +0000

Introduce `wasmtime::Store::try_new`, which handles OOM (#12415)* Introduce `wasmtime::Store::try_new`, which handles OOM`Store::new` is an infallible constructor, so there is not a direct way to makeit return an error on OOM. Additionally, it is one of the most-used functions inthe Wasmtime embedder API, so changing its signature to return a `Result` is anon-starter -- it would cause way too much pain. So instead we define`Store::try_new` which returns a `Result` and make `Store::new` call and unwrapthat new constructor.Part of https://github.com/bytecodealliance/wasmtime/issues/12069* update disas tests and fix winch* Disable concurrency support in `Store::try_new` OOM test* Add attributes that were lost in rebase List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance.rs

f1797bb1 - Don't pass module into `initialize_vmctx` (#12412)

Fri, 23 Jan 2026 21:38:11 +0000

Don't pass module into `initialize_vmctx` (#12412)* Don't pass module into `initialize_vmctx`Get it from `self`, which means we can't ever pass in the wrong module.* Avoid cloning an `Arc` via pin tricks List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance.rs

58ce6b8b - Remove unnecessary `memory_tys` param from `vm::Instance::new` (#12414)

Fri, 23 Jan 2026 20:40:41 +0000

Remove unnecessary `memory_tys` param from `vm::Instance::new` (#12414)We already have this information in the `InstanceAllocationRequest`, and byavoiding a parameter we can never accidentally pass the wrong memory types. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/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/vm/instance.rs

eff3be97 - Use `self` offsets to initialize an `Instance`'s vmctx (#12378)

Tue, 20 Jan 2026 23:39:04 +0000

Use `self` offsets to initialize an `Instance`'s vmctx (#12378)Rather than passing them in, which allows for the possiblity of passing thewrong offsets in. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance.rs

fae9e6af - add missing may-block checks for sync-to-sync guest-to-guest calls (#12282)

Thu, 08 Jan 2026 22:16:30 +0000

add missing may-block checks for sync-to-sync guest-to-guest calls (#12282)* add missing may-block checks for sync-to-sync guest-to-guest callsPreviously, we weren't updating or checking the may-block status of a taskacross sync-to-sync, guest-to-guest calls, meaning we were allowing blocking incases we shouldn't have.This fixes that by adding a new `task_may_block` field to `VMComponentContext`,plus code to update it every time we switch threads or do a sync-to-sync,guest-to-guest call. We use that field as the source of truth about whether ablocking operation is permitted.I've updated various tests to match, and Luke has an item on his to-do list toadd sad-path coverage for various cases to the upstream `component-model` testsuite.* address review feedback and fix component_instance_size_limit test* remove `TaskMayBlock` type per review feedback* bless disas tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/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/vm/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/vm/instance.rs

02155232 - Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)

Wed, 15 Oct 2025 00:03:52 +0000

Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)* Wasmtime: implement debug instrumentation and basic host API to examine runtime state.This PR implements ideas from the [recent RFC] to serve as the basisfor Wasm (guest) debugging: it adds a stackslot to each functiontranslated from Wasm, stores to replicate Wasm VM state in thestackslot as the program runs, and metadata to describe the format ofthat state and allow reading it out at runtime.As an initial user of this state, this PR adds a basic "stack view"API that, from host code that has been called from Wasm, can examineWasm frames currently on the stack and read out all of their localsand stack slots.Note in particular that this PR does not include breakpoints,watchpoints, stepped execution, or any sort of user interface for anyof this; it is only a foundation.This PR still has a few unsatisfying bits that I intend to address:- The "stack view" performs some O(n) work when the view is initially taken, computing some internal data per frame. This is forced by the current design of `Backtrace`, which takes a closure and walks that closure over stack frames eagerly (rather than work as an iterator). It's got some impressive iterator-chain stuff going on internally, so refactoring it to the latter approach might not be *too* bad, but I haven't tackled it yet. A O(1) stack view, that is, one that does work only for frames as the host API is used to walk up the stack, is desirable because some use-cases may want to quickly examine e.g. only the deepest frame (say, running with a breakpoint condition that needs to read a particular local's value after each step).- It includes a new `Config::compiler_force_inlining()` option that is used only for testing that we get the correct frames after inlining. I couldn't get the existing flags to work on a Wasmtime config level and suspect there may be an existing bug there; I will try to split out a fix for it.This PR renames the existing `debug` option to `native_debug`, todistinguish it from the new approach.[recent RFC]: https://github.com/bytecodealliance/rfcs/pull/44* Update to new APIs on Cranelift side.* Test update.* Adjust objdump printing of InstPos on frame progpoints; and adjust progpoint collapsing.* Convert to iterator form.* Fix path in native-debug tests (debug -> native_debug rename).* Enforce that `debug_instrumentation` can only be enabled when feature is enabled.* Add missing assert.* Use builtin knob for forcing intra-module inlining instead.* Review feedback:- Make StackView own the current frame rather than handing it out. This prevents the current frame (`FrameView`) from walking away and hiding somewhere it shouldn't, to be used unsoundly later.- Assert no-GC during stack walk.* Merge debug-instrumentation hooks on FuncEnvironment into before/after hooks.* Review feedback: avoid downcasting funcs twice.* Add debug feature to `wasmtime` crate's defaults.* Review feedback: u32s for local and stack indices in debug host API.* Use *const u8 as stack pointers and `with_exposed_provenance` in debug API.* Remove some `srcloc` plumbing in Wasm translator.* Rename native-debug back to debug, and make the new thing "guest debugging".* rustfmt in debugging test.* fix disas test after guest-debug CLI option rename.* Review feedback: no separate debug-instrumentation hooks on FuncEnvironment.* Review feedback: update doc comment on `Config::guest_debug`.* Review feedback: rename `generate_debuginfo` to `debug_native` in tunables.* Review feedback: miscellaneous comments.* Review comment: fix wording in safety conditions.* revert wasi-common submodule update* Properly root values in debug frame slots.Fixes #11841.* Fix non-`debug`-feature build.* Review feedback: naming.* Ignore tests that compile modules in miri. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance.rs

4e8ab840 - Refine raw `VMContext` helpers (#11670)

Wed, 10 Sep 2025 20:07:19 +0000

Refine raw `VMContext` helpers (#11670)This redefines `Instance::from_vmctx` as a function from`NonNull` to `NonNull` to canonicalize the singlelocation that pointer arithmetic is done but otherwise require callersto handle the safety requirements of safe references and such. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance.rs

79419198 - Don't unwrap results of const-eval (#11557)

Thu, 28 Aug 2025 19:50:56 +0000

Don't unwrap results of const-eval (#11557)While all const expressions executed at runtime are valid they can stillfail due to GC OOM or failure to allocate more GC memory. As a resultall `unwrap()` on `eval(...)` is removed in favor of propagatingupwards the result.Closes #11469 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance.rs

900370bc - Make core wasm libcalls sound (#11496)

Thu, 21 Aug 2025 22:05:11 +0000

Make core wasm libcalls sound (#11496)* Make core wasm libcalls soundThis commit updates the signature of core wasm libcalls to look morelike component libcalls where the instance argument is just an id, notan actual pointer. This is required to make them sound because otherwiseit's possible to, in safe Rust, acquire two mutable pointers to the sameinstance. Implementing this change is made possible by the many manyprevious refactors to how all of these internals work. All that wasrequired here was changing type signatures and minor updates to theorder of operations inside of libcalls.Closes #11178* Fix wmemcheck build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance.rs

2d25f862 - WebAssembly exception-handling support. (#11326)

Thu, 21 Aug 2025 02:55:44 +0000

WebAssembly exception-handling support. (#11326)* WebAssembly exception-handling support.This PR introduces support for the [Wasm exception-handling proposal],which introduces a conventional try/catch mechanism to WebAssembly. ThePR supports modules that use `try_table` to register handlers for alexical scope; and provides `throw` and `throw_ref` that allocate (inthe first case) and throw exception objects.This PR builds on top of the work in #10510 for Cranelift-levelexception support, #10919 for an unwinder, and #11230 for exceptionobjects built on top of GC, in addition a bunch of smaller fix andenabling PRs around those.[Wasm exception-handling proposal]: https://github.com/WebAssembly/exception-handling/prtest:full* Permit UnwindToWasm to have unused fields in Pulley builds (for now).* Resolve miri-caught reborrowing issue.* Ignore exceptions tests in miri for now (Pulley not supported).* Use wasmtime_test on exceptions tests.* Get tests passing on pulley platforms* Add a check to `supports_host` for the generated test and assert failure also when that is false.* Remove `pulley_unsupported` test as it falls out of `#[wasmtime_test]`* Remove `exceptions_store` helper as it falls out of `#[wasmtime_test]`* Remove miri annotations as they fall out of `#[wasmtime_test]`* Remove dead import* Skip some unsupported tests entirely in `#[wasmtime_test]`If the selected compiler doesn't support the host at all then there's noneed to run it. Actually running it could misinterpret `CraneliftNative`as "run with pulley" otherwise, so avoid such false negatives.* Cranelift: dynamic contexts: account for outgoing-args area.---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/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/vm/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/vm/instance.rs

d1397130 - Make const-expr evaluation `async` (#11468)

Wed, 20 Aug 2025 17:27:05 +0000

Make const-expr evaluation `async` (#11468)* Make const-expr evaluation `async`This commit is extracted from #11430 to accurately reflect howconst-expr evaluation is an async operation due to GC pauses that mayhappen. The changes in this commit are:* Const-expr evaluation is, at its core, now an `async` function.* To leverage this new `async`-ness all internal operations are switched from `*_maybe_async` to `*_async` meaning all the `*_maybe_async` methods can be removed.* Some libcalls using `*_maybe_async` are switch to using `*_async` plus the `block_on!` utility to help jettison more `*_maybe_async` methods.* Instance initialization is now an `async` function. This is temporarily handled with `block_on` during instance initialization to avoid propagating the `async`-ness further upwards. This `block_on` will get deleted in future refactorings.* Const-expr evaluation has been refactored slightly to enable having a fast path in global initialization which skips an `await` point entirely, achieving performance-parity in benchmarks prior to this commit.This ended up fixing a niche issue with GC where if a wasm execution wassuspended during `table.init`, for example, during a const-exprevaluation triggering a GC then if the wasm execution was cancelled itwould panic the host. This panic was because the GC operation returned`Result` but it was `unwrap`'d as part of the const-expr evaluationwhich can fail not only to invalid-ness but also due to "computation iscancelled" traps.* Fix configured build* Undo rebase mistake List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance.rs