Changes in vm.rs

3764e757 - Refactor borrow state tracking for async tasks (#12550)

Tue, 10 Feb 2026 03:15:51 +0000

Refactor borrow state tracking for async tasks (#12550)* Refactor borrow state tracking for async tasksThis commit is a somewhat deep refactoring of how the state of`borrow` is managed for both the host and the guest with respect toasync tasks. This additionally refactors how some async task managementis done for host-called functions.The fundamental problem being tackled here is #12510. In that issue itwas discovered that the way `CallContext`, the borrow tracking mechanismin Wasmtime, is managed is incompatible with async tasks. Specificallythe previous assumption of the scope being mutated for a borrow issomewhere on the call stack is no longer true. It's possible for anasync task to be suspended, for example, and then a sibling task drops aborrow which should update the scope of the suspended task. There were anumber of other small issues I noticed here and there which this PRadditionally has tests for, all of which failed before this change andpass afterwards.The manner in which borrow state is manipulated is a pretty old part ofthe component model implementation dating back to the originalimplementation of resources. I decided to forgo any possible quick fixand have attempted to more deeply refactor and integrate async tasksinto all of this infrastructure. A list of the changes made here are:* The `CallContexts` structure, a stack of `CallContext`, was removed. Tasks now directly store a `CallContext` which is the source of truth for borrow tracking for that call, and it does not move from this location. The store `CallContexts` is now deleted in favor of updating the `Option` in the store to be an `enum` of either concurrent state or a stack. In this manner the old stack-based structure is still used sometimes, but it's impossible to reach when concurrency is enabled.* Entry to the host from guests now reliably pushes a `HostTask` into the store. Previously where a frame were always pushed into a `CallContext` a `HostTask` is pushed into the store. This is still expected to be a bit too expensive for cheap host calls, but it doesn't meaningfully change the performance profile of before.* The `resource_enter_call` and `resource_exit_call` libcalls have been removed. These are now folded into the `enter_sync_call` and `exit_sync_call` libcalls. Emission of these hooks has been updated accordingly. The concept of entering a call more generally has been removed. This is more formally known in the async world as a task starting, so the task creation is now responsible for the demarcation of entering a call. Additionally this means that the concept of exiting a call has somewhat gone away. Instead this method was renamed to `validate_scope_exit` which double-checks that a borrow-scope can be exited but doesn't actually remove the task. Task removal is deferred to preexisting mechanisms.* Management of a `GuestTask`'s previous `Option` field, for example taking/restoring and pushing/popping onto `CallContexts` is now all gone. All related code is outright deleted as the `GuestTask`'s now non-optional `CallContext` field is the source of truth.* The `ConcurrentState` structure now stores a `CurrentThread` enum instead of `Option`. This represents how the currently executing thread could be a host thread, not just a guest thread, which is required for borrow-tracking.* `HostTask` creation in `poll_and_block` and `first_poll`, the two main entrypoints of async host tasks when called by the guest, is now externalized from these functions. Instead these functions assume that the currently running thread is already a `HostTask` of some kind.* In `poll_and_block` the host's result is no longer stored in the guest task but in the host task instead.Overall this enables the `*.wast` test for #12510 to fix the originalissue. This then adds new tests to ensure that cleanup of variousconstructs happens appropriately, such as cancelling a host task shouldclean up its associated resources. Additionally synchronously calling anasync host task no longer leaks resources in a `Store` and shouldproperly clean up everything.There is still more work to do in this area (e.g. #12544) but that'sgoing to be deferred to a future PR at this point.Closes #12510prtest:full* Review comments/CI fixes List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.rs

dd47158c - Do not allocate when cloning `ModuleRuntimeInfo` (#12413)

Fri, 23 Jan 2026 22:23:38 +0000

Do not allocate when cloning `ModuleRuntimeInfo` (#12413)We need to clone the info from the allocation request, into the allocatedinstance, so we should keep it a cheap operation. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.rs

17899c88 - Share empty `ModuleRuntimeInfo`s across all stores in an engine (#12409)

Fri, 23 Jan 2026 21:01:54 +0000

Share empty `ModuleRuntimeInfo`s across all stores in an engine (#12409)* Share empty `ModuleRuntimeInfo`s across all stores in an engineThis avoids an `Arc`- and `Box`-allocation during `Store` creation.* Fix no-runtime build* Pin x86-64_macos build to nightly to avoid a rustc bug List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.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.rs

96e19700 - Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

Wed, 07 Jan 2026 17:08:11 +0000

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`Instead of `anyhow::Error`.This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`module, updates the prelude to include these new error-handling types, redirectsour top-level `wasmtime::{Error, Result}` re-exports to re-export`wasmtime::error::{Error, Result}`, and updates various use sites that weredirectly using `anyhow` to use the new `wasmtime` versions.This process also required updating the component macro and wit-bindgen macro touse the new error types instead of `anyhow`.Part of https://github.com/bytecodealliance/wasmtime/issues/12069* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense* cargo fmt* Move `crate::error::Thing` to `crate::Thing` where it makes sense List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.rs

1d738975 - Use `core::convert::Infallible` instead of our own `Uninhabited` type (#12115)

Wed, 03 Dec 2025 21:32:48 +0000

Use `core::convert::Infallible` instead of our own `Uninhabited` type (#12115)* Use `core::convert::Infallible` instead of our own `Uninhabited` typeI didn't realize that the standard library already had an uninhabited typeavailable for us to reuse.* Actually remove the uninhabited module and its re-exports List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.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.rs

e4190de8 - Debugging: add a debugger callback mechanism to handle debug events. (#11895)

Wed, 22 Oct 2025 22:25:07 +0000

Debugging: add a debugger callback mechanism to handle debug events. (#11895)* Debugging: add a debugger callback mechanism to handle debug events.This PR adds a notion of "debug events", and a mechanism in Wasmtime toassociate a "debug handler" with a store such that the handler isinvoked as-if it were an async hostcall on each event. The asynchandler owns the store while its future exists, so the whole "world"(within the store) is frozen and the handler can examine any state itlikes with a `StoreContextMut`.Note that this callback-based scheme is a compromise: eventually, wewould like to have a native async API that produces a stream of events,as sketched in #11826 and in [this branch]. However, the async approachimplemented naively (that is, with manual fiber suspends and with statepassed on the store) suffers from unsoundness in the presence of droppedfutures. Alex, Nick and I discussed this extensively and agreed that the`Accessor` mechanism is the right way to allow for a debugger to have"timesliced"/"shared" access to a store (only when polled/when an eventis delivered), but we will defer that for now, because it requiresadditional work (mainly, converting existing async yield points in theruntime to "give up" the store with the `run_concurrent` mechanism).I'll file a followup issue to track that. The idea is that we caneventually build that when ready, but the API we provide to a debuggercomponent can remain unchanged; only this plumbing and the glue to thedebugger component will be reworked.With this scheme based on callbacks, we expect that one should be ableto implement a debugger using async channels to communicate with thecallback. The idea is that there would be a protocol where the callbacksends a debug event to the debugger main loop elsewhere in the executor(e.g., over a Tokio channel or other async channel mechanism), and whenthe debugger wants to allow execution to continue, it sends a "continue"message back. In the meantime, while the world is paused, the debuggercan send messages to the callback to query the `StoreContextMut` it hasand read out state. This indirection/proxying of Store access isnecessary for soundness: again, teleporting the Store out may look likeit almost works ("it is like a mutable reborrow on a hostcall") exceptin the presence of dropped futures with sandwiched Wasm->host->Wasmsituations.This PR implements debug events for a few cases that can be caughtdirectly in the runtime, e.g., exceptions and traps raised just beforere-entry to Wasm. Other kinds of traps, such as those normallyimplemented by host signals, require additional work (as in #11826) toimplement "hostcall injection" on signal reception; and breakpoints willbe built on top of that. The point of this PR is only to get the initialplumbing in place for events.[this branch]: https://github.com/cfallin/wasmtime/tree/wasmtime-debug-async* Add some more tests.* Review feedback: comment updates, and make `debug` feature depend on `async`.* Review feedback: debug-hook setter requires guest debugging to be enabled.* Review feedback: ThrownException event; handle block_on errors; explicitly list UnwindState cases.* Add comment about load-bearing Send requirement.* Fix no-unwind build.* Review feedback: pass in hostcall error messages while keeping the trait object-safe.Co-authored-by: Alex Crichton * Ignore divide-trapping test on Pulley for now.---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.rs

0dd73cc7 - feat(no_std): Add custom sync primitives support via C API (#11836)

Thu, 16 Oct 2025 19:01:41 +0000

feat(no_std): Add custom sync primitives support via C API (#11836)* Add custom-sync-primitives feature for no_std environmentsThis adds a new `custom-sync-primitives` feature that allows embeddersto provide their own synchronization primitives through a C API. Thisis particularly useful for kernel and embedded environments that needcustom lock implementations.The implementation follows the existing pattern of `custom-virtual-memory`and `custom-native-signals`, providing host-provided implementations ofOnceLock and RwLock through callback functions defined in the C API.* assume no_std in has_custom_sync flag* updating panic on contention error messages in sync_nostd.rs* inlining free in drop in custom/sync.rs* simplifying custom/sync.rs to delegate lazy initialization to the embedder* Consolidate no_std sync implementations and add RwLock-specific C API* Minor cleanup* adding custom_sync support to min-platform example* adding multithreaded TLS using pthread to min-platform example* addressing PR comments:Remove *_new files from capi sync api.Implement Drop-based lock releasingUpdate documentation + minor changes* fixes min-platform example for sync primitivesUse heap allocation to avoid deadlock in the implementation with no heap allocation.Use compare-and-swap for lazy initialization of rw lock for thread safety.* upgrade cbindgen in CI to 0.29* undo accidental edits to cbindgen generated header file List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.rs

becdee57 - Add PoolingAllocatorMetrics (#11490)

Fri, 22 Aug 2025 16:04:42 +0000

Add PoolingAllocatorMetrics (#11490)This exposes some basic runtime metrics derived from the internal stateof a `PoolingInstanceAllocator`.Two new atomics were added to PoolingInstanceAllocator: `live_memories`and `live_tables`. While these counts could be derived from existingstate it would require acquiring mutexes on some inner state. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.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.rs

6e21cf1f - Remove `StoreOpaque::async_yield_impl` (#11482)

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

Remove `StoreOpaque::async_yield_impl` (#11482)* Remove `StoreOpaque::async_yield_impl`Now that we have all this fancy support for natively running `async`things this commit refactors fuel/epochs to use it. This simplifies the`VMStore` trait, removes a usage of `block_on`, and helps keep the`async` boundary close to the libcall entrypoint rather than furtherdown the stack. This all in turn enables using rustc to check ourstack-locals for non-`Send` values instead of pinky promising that we'redoing the right thing everywhere.* Clean up some code movement and comments* Fix a merge conflict List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.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.rs

f8177c20 - Refactor `InstanceAllocator` trait impl split (#11457)

Tue, 19 Aug 2025 16:43:51 +0000

Refactor `InstanceAllocator` trait impl split (#11457)Prior to this commit Wasmtime had an `InstanceAllocatorImpl` trait witha number of required methods as well as an `InstanceAllocator` traitwith a number of provided impls. The `InstanceAllocator` trait isimplemented for everything implementing `InstanceAllocatorImpl` to forceusers to be unable to override the default methods. When adding `async`support internally to Wasmtime these are going to need to be`#[async_trait]`-annotated-traits which adds a cost to `async` functionsas a future needs to be heap-allocated.The goal of this commit is to make this future `async`-ification a bitmore optimal. Notably the `InstanceAllocator` trait is removed andreplaced with inherent methods on `impl dyn InstanceAllocatorImpl`.After that the previous `InstanceAllocatorImpl` trait was renamed to`InstanceAllocator` meaning that there's just one `InstanceAllocator`trait which has inherent methods which cannot be overridden. Aconsequence of this is that the inherent methods are also forced to dovirtual dispatch unlike before where they would internally usemonomorphization to have static dispatch. Given the complexity ofinstance allocation this is expected to be a negligible cost, however.The main benefit is that `allocate_module`, `allocate_tables`, and`allocate_memories` all get to be native `async` functions without thecost of `#[async_trait]`. Only allocation of a single table/memory willrequire an allocation of a future which in profiling helps reduce thecost of instantiation slightly.Note that `#[async_trait]` is not currently used, this commit is justpreparation for its eventual use. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.rs

f828ce08 - Add a helper always-`Sync` utility to Wasmtime (#11453)

Mon, 18 Aug 2025 22:08:54 +0000

Add a helper always-`Sync` utility to Wasmtime (#11453)* Add a helper always-`Sync` utility to WasmtimeThis commit adds a newtype wrapper to Wasmtime, `AlwaysMut`, which isunconditionally `Sync` if the stored type is `Send`. This is similar toa `Mutex` where it promotes a `Send` bound to a `Sync` bound, butit's unlike `Mutex` in that `AlwaysMut` has no synchronization.The reason that this is safe is that `AlwaysMut` completely disallowsaccess to the underlying data through `&self` and requires `&mut self`.This is similar to how `Mutex::get_mut` is safe, for example.This type cleans up a preexisting `unsafe impl Sync` block in funcrefmanagement around `SendSyncBump` (`bumpalo::Bump` is `Send`, not `Sync`,but we only access it through `&mut self`). This then additionallyremoves `unsafe impl Sync for StoreFiber` which, upon reflection, is notsound because we don't ever constraint the store's `T` type to `Sync`,only `Send`. This is effectively no change throughout Wasmtime, however,as fibers are only accessed with `&mut`.Overall this is mostly just internal refactoring to reduce the amount of`unsafe` inside of Wasmtime and to add a new utility to use in thefuture too.* Fix configured build* Review comments* Fix configured build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.rs

82941262 - Require a store in `catch_unwind_and_record_trap` (#11441)

Mon, 18 Aug 2025 20:11:15 +0000

Require a store in `catch_unwind_and_record_trap` (#11441)* Require a store in `catch_unwind_and_record_trap`This commit does some preparatory refactoring for #11326 to ensure thata store is available when trap information is being processed. Currentlythis doesn't leverage the new parameter but it should be leverage-ablein #11326.* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.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/vm.rs

aef5eeb5 - Refactor internals of table initialization and management (#11416)

Tue, 12 Aug 2025 22:32:11 +0000

Refactor internals of table initialization and management (#11416)* Refactor const-eval to use `Val`, not `ValRaw`This commit refactors the evaluation of constant expressions duringinstantiation for example to use `Val` instead of `ValRaw`. Previouslythe usage of `ValRaw` meant that wasm was disallowed from performing aGC during const evaluation, but currently constant expressions canindeed perform a GC. The goal of this commit is to lift this limitation.This is expected to be a minor slowdown for modules that hit this path,but most modules shouldn't hit this in a hot loop since LLVM doesn'tgenerate modules that use this branch of const eval.The usage of `Val` brings a number of benefits and refactoringsassociated with it:* Const-evaluation is generally safer than before since everything is higher-level.* GC types in const-eval were almost already using `Val` meaning that there's actually fewer conversions now.* Instantiation code was refactored to use `wasmtime::*`-API types instead of low-level VM types. This deduplicates a good deal and lifts complexity out of the raw VM bits.Another issue that this commit fixes is to change how tableinitialization is modeled internally in`vm::Instance::table_init_segment`. Previously this was done by removingthe tables from an instance to get a split borrow into the store and thetable. This is not valid though because if, during initialization, a GCis performed then the table is not present to find roots through thetable. This function is refactored to scope borrows to within a loopinstead of over a loop via various refactorings and such and usage ofhigher level APIs. This is again, like above, expected to pessimizeperformance but this is also not known to be a hot path for modules atthis time.* Remove the `TableElement` typeThis commit is a refactoring of how tables work within Wasmtime to avoidfunneling table elements through a `TableElement` enum internally.Instead methods are "exploded" to `grow_{gc_ref,func,cont}` which means,for example, funcrefs don't need a GcStore. The main motivation for thischange was to avoid the idiom where `TableElement` represents a cloned,but unrooted, GC reference.Prior to this commit there were a number of subtle bugs in the tablecode for Wasmtime where write barriers were forgotten on `table.init`,`table.set` (via the embedder API), and `table.grow`. While `table.fill`correctly handled the GC references it was awkward to get everythingelse working consistently so I opted to remove `TableElement` entirelyto make it more clear that `&VMGcRef` is ubiquitously used meaning thatthe write barriers, for example, are the same as other parts of theWasmtime codebase.This has a few extra tests for "make sure this doesn't leak" to ensurethat GC works correctly with new barriers in place.* Fix some lints and warnings* Fix wmemcheck build* Review comments* Optimize const eval and global initialization* Fix compile* Fix lints List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.rs

28f97835 - Remove a dead trait method (#11407)

Fri, 08 Aug 2025 21:28:35 +0000

Remove a dead trait method (#11407)* Remove a dead trait methodMade obsolete from previous refactorings, so no need to keep this anymore.* Fix unused import* Fix missing import List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.rs

b500820e - Add support for the Linux PAGEMAP_SCAN ioctl (#11372)

Fri, 08 Aug 2025 16:19:07 +0000

Add support for the Linux PAGEMAP_SCAN ioctl (#11372)* WIP: use the pagemap_scan ioctl to selectively reset an instance's dirty pages* Less hacky, and supporting tables, too* Bugfixes* WIP: memcpy instead of pread* Refactor support for pagemap* Don't hold a raw pointer to the original data, plumb through an `Arc` to have a safe reference instead.* Update pagemap bindings to latest version of abstraction written.* Include pagemap-specific tests.* Use a `PageMap` structure created once-per-pool instead of a static-with-a-file.* Refactor to use the "pagemap path" unconditionally which blends in the keep_resident bits.* Improve safety documentationprtest:full* Fix some lints* Skip ioctl tests when it's not supported* Fix a memory leak by moving impls around* Fix no vm build* Review comments* Add more pagemap-specific documentation* Add more docs, refactor implementation slightly* Improve `category_*` docsBasically forward to the Linux kernel source itself.* Fix compile* Make pagemap integration resilient across forks* Fix non-pooling-allocator-build* Fix portability issues of new test* Actually use config on macos---------Co-authored-by: Till Schneidereit List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm.rs