Changes in wasmtime

7e0331c2 - Debugging: refactor stack frame cursor into frame handle abstraction. (#12566)

Wed, 11 Feb 2026 23:00:00 +0000

Debugging: refactor stack frame cursor into frame handle abstraction. (#12566)* Debugging: refactor stack frame cursor into frame handle abstraction.This addresses some of the issues described #12486: we need the abilityto keep a handle to a stack frame as long as execution is frozen, andkeep multiple of these handles around, alongside the `Store`, withoutany handle directly holding a borrow of the store.The frame handles work by means of an "execution version" scheme: theidea is that whenever any execution resumes in a given store, allhandles to existing frames could be invalidated, but if no suchexecution occurs, all handles should still be valid. A tuple of(globally unique for process lifetime) store ID, and execution versionwithin that store, should be sufficient to uniquely identify anyfrozen-stack period during execution. This accomplishes cheap handleinvalidation without the need to track existing handles.This PR also implements a cache of parsed frame-table data. Previouslythis was lazily parsed by the cursor as it walked up a stack, but withmultiple handles hanging around, and with handles meant to be cheap tohold and clone, and with handles being invalidated eagerly, it makesmuch more sense to persist this parsed metadata at the `Store` level.(It cannot persist at the `Engine` level because PCs are local perstore.)* Re-bless disas tests (offsets in VMStoreContext changed).* Handle invalidation tests.* Review comments, and make API return `Result`s rather than panic'ing on stale handles.* Review feedback.* Doc-comment link fix.* Review feedback.* cfg-gate Activation method to `debug` feature only.* Fix unused-import warning in no-debug cfg.* Fix doc link (again, after rename from latest feedback). List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs

2811ee83 - feat(style,doc): added typos-cli workspace configuration (#12827)

Tue, 24 Mar 2026 22:00:00 +0000

feat(style,doc): added typos-cli workspace configuration (#12827)* init config values* more manual changes* typos write* revert certain changes* misused, tightened up hex encoding List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/traphandlers.rs

838ed2d0 - Enable `allow_attributes_without_reason` (#11195)

Mon, 07 Jul 2025 21:00:00 +0000

Enable `allow_attributes_without_reason` (#11195)* Enable `allow_attributes_without_reason`This commit enables the `clippy::allow_attributes_without_reason` forthe `wasmtime` crate which previously forcibly allowed it. The reasonthis was allowed was that when the workspace was first migrated theWasmtime crate had too many instances that I was willing to fix. I'venow come back around and tried to fix everything.In short: ideally delete `#[allow]`, otherwise use `#[expect]`,otherwise use `#[allow]`.prtest:full* Adjust some directives* Fix some warnings* Fix stack switching size tests on unix* Don't have a conditional `Drop` impl* Force `testing_freelist` method to be usedToo lazy to write `#[cfg]`, but not too lazy to write a test. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/traphandlers/coredump_enabled.rs

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

Wed, 03 Dec 2025 01:00: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/throw.rs

92f1829e - miri: add guest-debugging, including frame accesses. (#12575)

Thu, 12 Feb 2026 23:00:00 +0000

miri: add guest-debugging, including frame accesses. (#12575)* miri: add guest-debugging, including frame accesses.The fix to `vm_store_context` provenance in `record_unwind`/`unwind`is a little weird to me. I was seeing mut access to the`vm_store_context` via `store.vm_store_context_mut()` in`record_unwind` (before this diff) then access via the previouslysaved raw pointer in the `CallThreadState`, which was registered asinvalid and I believe is indeed invalid. This was only manifestingwhen setting `Config::guest_debug`, even without the frame-handleaccesses added here. I didn't dig into the exact diff in codegen orruntime behavior that caused this but in any case, accessing`vm_store_context` via these two different paths (with one mut)appears to be unsound in any case. The fix here is to set the unwindstate via the raw pointer in `CallThreadState` since that's the onlypath that the subsequent `unwind` has access to.Unrelated but useful: `ci/miri-provenance.test.sh` now accepts`MIRI_RUST_VERSION=+nightly` or whatnot, which is nice for runninglocally (I keep `stable` as my default toolchain).* Revert MIRI_RUST_VERSION in the CI script and add note about `rustup run` instead.* Add a bit more usage of debug API to Pulley provenance test.* Switch to using `Store`-derived `VMStoreContext` where available and re-deriving the raw pointer in `CallThreadState`.prtest:full List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/sys/unix/machports.rs/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/traphandlers/backtrace.rs

e126fd1d - Fix panicking overflow when calculating table sizes (#13244)

Thu, 30 Apr 2026 15:00:00 +0000

Fix panicking overflow when calculating table sizes (#13244)Return an error instead of panicking in the same manner that OOM ishandled. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/table.rs

ad56ff98 - Implement unsafe intrinsics for compile-time builtins (#11825)

Fri, 17 Oct 2025 00:00:00 +0000

Implement unsafe intrinsics for compile-time builtins (#11825)* Implement unsafe intrinsics for compile-time builtinsThis commit adds the extremely unsafe`wasmtime::CodeBuilder::expose_unsafe_intrinsics` method. When enabled, the Wasmbeing compiled is given access to special imports that correspond to direct,unchecked and unsandboxed, native load and store operations. These intrinsicsare intended to be used for implementing fast, inline-able versions of WASIinterfaces that are special-cased to a particular host embedding, for example.Compile-time builtins, as originally described in [theRFC](https://github.com/bytecodealliance/rfcs/pull/43), are basically made up ofthree parts:1. A function inliner2. Unsafe intrinsics3. Component composition to encapsulate the usage of unsafe intrinsics in a safeinterfacePart (1) has been implemented in Wasmtime and Cranelift for a little whilenow (see `wasmtime::Config::compiler_inlining`). This commit is part (2). Afterthis commit lands, part (3) can be done with `wac` and `wasm-compose`, althoughfollow up work is required to make the developer experience nicer and moreintegrated into Wasmtime so that the APIs can look like those proposed in theRFC.* fill out some more docs* fix non component model builds* start filling out the doc example* Factor abi params/returns out; truncate/extend pointers* Compile unsafe intrinsics on winch as well* prtest:full* have the macro define the signature* ignore tests in MIRI because MIRI can't compile Wasm* juggle pointer provenance in `Store::data[_mut]`* add a test for store data provenance and also fix it* use `VmPtr` for the store data pointer* finish writing unsafe intrinsics example* fix up docs and rules around only accessing data from `T` in a `Store`* Only reserve space for the intrinsics' `VMFuncRef`s if they are in use* use dangling pointers instead of options* Rename `StoreInner::data` to `data_no_provenance` and fix some accesses to use the method accessors* Add comments about the provenance juggling inside `StoreInner::data[_mut]`* only compile intrinsics that are usedTurns out we don't need to add phases, we already have the info available to dothis.* fix duplicate symbol names List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/provenance.rs

facc9925 - Enable warnings if `async` is disabled (#10145)

Wed, 29 Jan 2025 18:00:00 +0000

Enable warnings if `async` is disabled (#10145)* Enable warnings if `async` is disabledContinuation of work in #10131.This required a number of organizational changes to help cut down on`#[cfg]`, notably lots of async-related pieces from `store.rs` havemoved to `store/async_.rs` to avoid having lots of conditional imports.Additionally this removes all of the `#[cfg]` annotations on thosemethods already.Additionally the signature of `AsyncCx::block_on` was updated to be abit more general to ideally remove the need for `Pin` but it ended upnot panning out quite just yet. In the future it should be possible toremove the need for `Pin` at callsites though.* Rebase conflicts List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/mpk/enabled.rs

e4e9cabe - Bump MSRV to Rust 1.91.0 (#12392)

Thu, 22 Jan 2026 18:00:00 +0000

Bump MSRV to Rust 1.91.0 (#12392)* Bump MSRV to Rust 1.91.0Coupled with today's release of Rust 1.93.0prtest:full* Fix warnings about cpuid being safe* Fix nightly build flags List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/mpk/pkru.rs

4bb429aa - Use `try_new` for `Arc` in `MmapMemory::new` (#12851)

Thu, 26 Mar 2026 22:00:00 +0000

Use `try_new` for `Arc` in `MmapMemory::new` (#12851) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory/mmap.rs

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

Mon, 30 Mar 2026 18:00:00 +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/vm/memory/shared_memory.rs

2283e84f - Fix a panic with a massive `max_wasm_stack` configured (#12869)

Mon, 30 Mar 2026 18:00:00 +0000

Fix a panic with a massive `max_wasm_stack` configured (#12869)* Fix a panic with a massive `max_wasm_stack` configuredThis commit fixes a panic through a `checked_add(...).unwrap()` whichcan happen when `Config::max_wasm_stack` is configured to be a verylarge value. This is a mostly benign panic as it's unlikely this isconfigured much in the wild, but nevertheless seems like a good issuesto fix regardless.* Fix an overflow/OOM panic in pulleyprtest:full* Fix CI* Another CI fix* Fix test on 32-bit* Fix miri test List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/interpreter.rs

3b3f1e75 - Fix build on FreeBSD/aarch64 (#12820)

Sun, 22 Mar 2026 18:00:00 +0000

Fix build on FreeBSD/aarch64 (#12820) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/sys/unix/signals.rs

4c7c01dc - Debugging: add debugger support for `wasmtime serve`. (#12859)

Wed, 01 Apr 2026 01:00:00 +0000

Debugging: add debugger support for `wasmtime serve`. (#12859)This adopts a simple solution to #12776: it takes the "instance reuse"paradigm to the extreme, instantiating exactly one instance andserializing all requests into that one instance. This allows thedebugger component to operate on one `Store`, setting breakpoint stateand presenting its execution to the attached debugger as a singleprogram execution and minimizing impedance mismatches.This also adds an integration test that runs an existing wasi-httptest component under the debugger. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/libcalls.rs

b8f882d1 - Add support for fine-grained operator costs (#11572) (#12541)

Thu, 19 Feb 2026 19:00:00 +0000

Add support for fine-grained operator costs (#11572) (#12541)Introduce `OperatorCostStrategy` and `OperatorCost` to allow configuringper-operator fuel costs via `Config::operator_cost`. Previously, operatorcosts were hardcoded inline in both Cranelift and Winch code generation.Now the cost logic is centralized in `wasmtime-environ` and referencedfrom both backends via `tunables.operator_cost.cost(op)`.`OperatorCostStrategy` is an enum with two variants:- `Default`: reproduces the original hardcoded behavior (nop/drop/control flow cost 0, everything else costs 1).- `Table(Box)`: a per-operator cost table generated via `wasmparser::for_each_operator!`.Because `OperatorCostStrategy::Table` contains a `Box`, the type has adestructor. This makes `Tunables` non-trivially droppable, which preventsusing the `..Tunables::default_miri()` functional update syntax in constfunctions (E0493). To work around this, `default_miri`, `default_u32`,and `default_u64` are changed to non-const fns. None ofthese are called in const contexts, except in tests. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory/malloc.rs

b860c2c6 - Adjust behavior of 4gb memories with custom page sizes (#12884)

Mon, 30 Mar 2026 14:00:00 +0000

Adjust behavior of 4gb memories with custom page sizes (#12884)* Adjust behavior of 4gb memories with custom page sizesThis commit adjust what happens when a linear memory grows up to 4gblarge when custom page sizes are used. This is an open question in theupstream proposal at WebAssembly/custom-page-sizes#45 but without anyspecial handling a return value of -1 is ambiguous if it succeeded orfailed. For now eagerly trap memory operations reaching these conditionswhile the upstream specification question is resolved.* Fix CI* Debug CI failureprtest:full* Fix 32-bit platforms List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory.rs

0afe5fc7 - Handle more failures deallocating pooled memroy (#12888)

Mon, 30 Mar 2026 23:00:00 +0000

Handle more failures deallocating pooled memroy (#12888)* Handle more failures deallocating pooled memroyThis commit replaces a few panics in the pooling allocator witherror-handling of what happens at runtime. This is a defense-in-depthmeasure to ensure that the pooling allocator doesn't panic at runtimeand instead handles errors where possible.The first path fixed is in `deallocate_memory` where resetting a slotcould result in an error being returned on non-Linux platforms, and ifthis happened it would cause a panic. The error is instead gracefullyhandled by continuing slot deallocation but avoiding putting the imageitself back into memory. This leaves the slot in an `Unknown` statewhich is already handled by resetting the state upon reuse. The mainconsequence here is that future statistics about resident bytes won't beaccurate, but these are already inaccurate on non-Linux platformsanyway, so there's no loss.The second path fixes is in flushing a `DecommitQueue` where`decommit_pages` was asserted to succeed. Instead now the error ishandled by dropping all images and leaving slots in an `Unknown` state,similar to `deallocate_memory`.* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator/pooling.rs/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator/pooling/decommit_queue.rs

9bc302ad - Reduce type complexity of `InstanceAllocator` async functions (#12887)

Mon, 30 Mar 2026 15:00:00 +0000

Reduce type complexity of `InstanceAllocator` async functions (#12887)This is a follow-on to #12849 to try to simplify some of the resultingsignatures a bit. Notably the `Result<..., OutOfMemory>` is now packagedup directly into the output future, so the functions still retain a sortof "async trait" feel even though they're still incompatible with`#[async_trait]` (and can't be defined with that anyway). List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator/on_demand.rs

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

Fri, 09 Jan 2026 19:00:00 +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/vm/instance/allocator/pooling/gc_heap_pool.rs

c33c8b8d - Add some more metrics to the pooling allocator (#11789)

Tue, 07 Oct 2025 04:00:00 +0000

Add some more metrics to the pooling allocator (#11789)* Add some more metrics to the pooling allocatorThis commit adds a few more metrics to the `PoolingAllocatorMetrics`type along the lines of accounting for more items as well as the unusedslots in the pooling allocator. Notably the count of unused memory andtable slots is exposed along with the number of bytes which are keptresident in these slots despite them not being in use. This involved abit of plumbing to thread around the number of bytes that are actuallykept resident to some more locations but is otherwise a prettystraightforward plumbing of accounting information we already hadinternally.* Fix configured build* Add some docs* Only run new test on Linux* Try to fix ASANprtest:full* Shrink pooling size in tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator/pooling/index_allocator.rs/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator/pooling/unix_stack_pool.rs