Changes in component.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/component.rs

57f899c4 - Move threads to their own index space in components (#12516)

Wed, 04 Feb 2026 19:42:35 +0000

Move threads to their own index space in components (#12516)* Move threads to their own index space in componentsThis accounts for WebAssembly/component-model#600 and mostly updatesvarious test expectations to match this.Closes #11954* Fix conditional compiles List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component.rs

4d129904 - Check may-leave flags in trampolines, not Rust (#12427)

Tue, 03 Feb 2026 20:01:03 +0000

Check may-leave flags in trampolines, not Rust (#12427)This commit moves all may-leave flag handling into compiled trampolinesrather than doing this in Rust. This means it can't be forgotten on theRust side of things and will be slightly more efficient to boot. Thisthen additionally exempts some intrinsics from checking may-leave sinceWasmtime erroneously checked when it shouldn't have.Closes #12397Closes #12403 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component.rs

c09aa380 - deprecate `[Typed]Func::post_return[_async]` and make them no-ops (#12498)

Tue, 03 Feb 2026 19:13:45 +0000

deprecate `[Typed]Func::post_return[_async]` and make them no-ops (#12498)* deprecate `[Typed]Func::post_return[_async]` and make them no-opsWith the advent of the Component Model concurrency ABI and it's `task.return`intrinsic, post-return functions have been informally deprecated and areexpected to be removed for WASI 1.0 and the corresponding stable edition of theComponent Model. Consequently, it does not make sense anymore to requireembedders to explicitly call the post-return function after using`[Typed]Func::call[_async]`.As of this commit, `[Typed]Func::post_return[_async]` are no-ops. Instead, thepost-return function is called automatically as part of`[Typed]Func::call[_async]` if present, which is how`[Typed]Func::call_concurrent` has worked all along. In addition, this commitfixes and tests a couple of cases where the task and/or thread was beingdisposed of before the post-return function was called.* address review feedback* test post-return function in more scenariosSpecifically, I've split the `invoke_post_return` test into multiple tests:- using `TypedFunc::call`- using `TypedFunc::call_async` with concurrency support enabled- using `TypedFunc::call_async` with concurrency support disabled- using `Func::call_async` with concurrency support disabled- using `TypedFunc::call_concurrent`* remove GCC/clang-specific deprecation attributeThis broke the MSVC build.* bless bindgen output* remove obsolete post-return functions and fieldsNow that post-return calls are handled internally without requiring explicitaction by the embedder, we can avoid unnecessary bookkeeping. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component.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/component.rs

b856261d - refactor recursive reentrance checks (#12349)

Wed, 14 Jan 2026 22:27:49 +0000

refactor recursive reentrance checks (#12349)* refactor recursive reentrance checksThis commit makes a few changes related to recursive reentrance checks, instancepoisoning, etc.:- Implements the more restrictive lift/lower rules described in https://github.com/WebAssembly/component-model/pull/589 such that a component instance may not lower a function lifted by one of its ancestors, nor vice-versa. Any such lower will result in a fused adapter which traps unconditionally, preventing guest-to-guest recursive reentrance without requiring data flow analysis. - Note that this required updating several WAST tests which were violating the new rule, including some in the `tests/component-model` Git submodule, which I've updated. - This is handled entirely in the `fact` module now; I've removed the `AlwaysTrap` case previously handled by `wasmtime-cranelift`.- Removes `FLAG_MAY_ENTER` from `InstanceFlags`. It is no longer needed for guest-to-guest calls due to the above, and for guest-to-host-to-guest calls we can rely on either `FLAG_NEEDS_POST_RETURN` for sync-lifted functions or the `GuestTask` call stack for async-lifted functions.- Adds a `StoreOpaque::trapped` field which is set when _any_ instance belonging to that store traps, at which point the entire store is considered poisoned, meaning no instance belonging to it may be entered. This prevents indeterminant concurrent task state left over from the trapping instance from leaking into other instances.Note that this does _not_ include code to push and pop `GuestTask` instances forguest-to-guest sync-to-sync calls, nor for host-to-guest calls using e.g. thesynchronous `Func::call` API, so certain intrinsics which expect a `GuestTask`to be present such as `backpressure.inc` will still fail in such cases. I'lladdress that in a later PR.Also note that I made a small change to `wasmtime-wit-bindgen`, adding a `Send`bound on the `T` type parameter for `store | async` functions. This allowed meto recursively call `{Typed}Func::call_concurrent` from inside a host function,and it doesn't have any downsides AFAICT.Fixes #12128* bless bindgen expansions* bless disas tests* address review feedback* sync `trap.h` with `trap_encoding.rs`...and add const assertions to `trap.rs` to help avoid future divergence. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component.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/component.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/component.rs

cb97ae85 - allow recursive Wasm invocation from concurrent host functions (#12152)

Thu, 11 Dec 2025 23:03:58 +0000

allow recursive Wasm invocation from concurrent host functions (#12152)* allow recursive Wasm invocation from concurrent host functionsThe core changes here are:- remove an unnecessary assertion from `concurrent::prepare_call`- track instance states (e.g. backpressure, etc.) on a per `(Instance, RuntimeComponentInstanceIndex)` basis - both parts of that key are needed now that concurrent state is tracked on a per-store basis rather than a per-instance basis since `RuntimeComponentInstanceIndex`es are not globally uniqueWhile discussing the above with Alex, we realized the use of a `HashMap` totrack per-instance states was both pessimal and unnecessary. Consequently, I'vefolded that state into `ComponentInstance::instance_handle_tables`, renaming itto `instance_states`. That involved a fair amount of code churn, but doesn'tchange behavior except as described in the second bullet point above.Thanks to Alex for the test case!Fixes #12098Co-authored-by: Alex Crichton Signed-off-by: Joel Dice * use new `RuntimeInstance` type instead of tuplesSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component.rs

05a711f6 - Deduplicate static/dynamic host function code paths (#12146)

Thu, 11 Dec 2025 20:21:03 +0000

Deduplicate static/dynamic host function code paths (#12146)* Deduplicate static/dynamic host function code pathsThis commit refactors the `component/func/host.rs` file to deduplicatethe paths between static/dynamic host functions. Previously there was asignificant amount of duplication between the two which has beenexacerbated through time. This commit refactors the state of affairs toensure that all the shared logic between the two is in one location andthe only difference is what they're already doing different (e.g.lifting/lowering guts).The high-level goal here was to see if this was possible, but in the endthis feels like a much cleaner state of affairs than prior as far fewerdetails are duplicated across a few locations. The host functionbehavior is slightly more "dynamic" than before in the sense thatstatically-known signature has a few more type lookups than before, forexample, but this can be fixed in due time if necessary.* Fix compile warnings/issues List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component.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/component.rs

ec9b62ab - Enable borrowing components and stores mutable at the same time (#11987)

Fri, 07 Nov 2025 19:49:39 +0000

Enable borrowing components and stores mutable at the same time (#11987)* Use `OptionsIndex` more internally in componentsThis updates various runtimes bits for components to use `OptionsIndex`more aggressively and ultimately deletes the old `Options` type. The`Options` type is a heavyweight package of all possible options which iseffectively a duplication of what `OptionsIndex` points to, so that'sremoved in favor of directly accessing options.* Enable borrowing components and stores mutable at the same timeThis commit adds a new, safe, function to the `Instance` type forinternal use in Wasmtime which enables simultaneously borrowing the`Component`-within-the-`Instance` as well as the original store at thesame time. This is not possible to do in safe Rust when the store ismutable and must be implemented with `unsafe` code.The motivation for this commit is performance. In #11974 it wasdiscovered that the addition of a single `Arc::clone` was enough toreduce throughput in the embedding by 20%. While `Arc::clone` isgenerally cheap I can see how a "contended" `Arc::clone` could get quiteexpensive. This particular benchmark was running multiple instances ofthe same component across multiple threads which were all doing manyhost calls. Each host call, after the refactoring of #10959, containedan `Arc::clone` to the component itself. This in turn led to manythreads constantly incrementing/decrementing the `Arc::clone` count ofthe same `Arc` instance.At a high level this clone is not necessary. The component lives withinthe store and cannot be mutated/deleted during execution. Safe Rust,however, forbids access to the component and mutably using the store atthe same time. Thus, this helper function enters the picture. The goalhere is to remove the `Arc::clone` calls without requiring major surgeryor such to refactor the implementations of various functions throughoutWasmtime. The `unsafe` block used to implement this function documentsmore rationale as to why this should be safe.* Update crates/wasmtime/src/runtime/component/instance.rsCo-authored-by: Nick Fitzgerald ---------Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component.rs

e06fbf70 - Cooperative Multithreading (#11751)

Mon, 27 Oct 2025 21:39:35 +0000

Cooperative Multithreading (#11751)* Initial work* Almost compiling* Partially working* Cleanup* Fix merge* Cancellation and suspension refactoring* Remove printlns* Test with several threads* More testing* Cancellation* Fix cancellation for explicit suspends* Finish cancellation test* Store threads in the instance table* Deletion almost there* Tests all pass* Tighten up task deletion* Set thread state correctly* Store pairs of thread and task ids* Remove lift abi members* Cleanup unnecessary change* More cleanup* Cleanup* Revert cargo changes* Revert cargo changes* Comments* Comments on test* Update comments* Update comments* Add space that was removed in an earlier commit* Cleanup* Delete threads from the instance table* Revert cargo file* Remove dead code* Clippy changes* Clippy* Revert unnecessary changes* Revert unnecessary changes* Revert unnecessary changes* Revert unnecessary changes* Revert unnecessary changes* Review comments* Review feedback* Make thread IDs per-component-instance* Fix config* Tighten up completion* Clippy* Trigger full PR test* Move funcref table reading* Remove unused import* Formatting* Rename RemoveOnDrop* Review feedback* Review feedback* Move start thread closure* Review feedback* Review feedback* Correct feature for import* Review feedback* Disable failing tests* Enable fixed tests* Review feedback* Readd tests* Ignore task deletion test with Miri List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component.rs

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

Fri, 17 Oct 2025 00:01:54 +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/component.rs

8fbe4c2c - Fix some panics compiling components and resources (#11798)

Mon, 06 Oct 2025 22:36:55 +0000

Fix some panics compiling components and resources (#11798)In working on bytecodealliance/wasm-tools#2335 I found that there's afew test cases in wasm-tools which Wasmtime was panicking to compile.The issues were all related to resource types and how information wasn'tregistered ahead of time before it was translated from wasmparser'srepresentation to Wasmtime's representation. The high-level cause forthis had to do with how component and instance types are handled, asopposed to concrete components or instances themselves. This waseffectively a hole in Wasmtime's translation process for componentswhich has never been filled out since the original implementation ofresources. The reason that this never came up before is:* Most components don't currently import or export a component itself.* Most components don't currently import or export component or instance types (as opposed to values).One of these was required to trigger this issue. The solutionimplemented in this commit is to plumb the concept of an "abstractresource" which is part of a type but not actually ever used at runtimeexcept for type equality during type reflection. This is expected tohave little-to-no impact on real-world components given that thesesituations are rarely occurring. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component.rs

7e39c25e - move `ConcurrentState` from `ComponentInstance` to `Store` (#11796)

Mon, 06 Oct 2025 19:53:10 +0000

move `ConcurrentState` from `ComponentInstance` to `Store` (#11796)* move `ConcurrentState` from `ComponentInstance` to `Store`This has a few benefits:- No need to specify an instance when creating or piping from a stream or future.- No need to track the instance in an `Accessor`.- You may now execute tasks for multiple instances in a single event loop.The main drawback is that, if one of several instances within a single storetraps, it effectively means all instances have trapped, and the store can't beused to create new instances. The way to avoid that is to use separate storesfor instances which must be isolated from others.As a result of this change, a lot of code had to move from e.g. `impl Instance`to e.g. `impl StoreOpaque`, so the diff is pretty huge, but the changesthemselves are almost entirely non-functional.Fixes #11226Signed-off-by: Joel Dice * fix non-component-model-async buildSigned-off-by: Joel Dice * fix outdated doc commentSigned-off-by: Joel Dice * address review feedback- restore `ComponentStoreData` encapsulation- avoid conditional code duplication in `LiftContext::new`Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component.rs

6751ea79 - disallow exiting a component instance during a post-return call (#11688)

Thu, 11 Sep 2025 23:26:34 +0000

disallow exiting a component instance during a post-return call (#11688)* disallow exiting a component instance during a post-return callThis is a relatively recent change to the spec.In order to check the `may_leave` flag in all the relevant intrinsics, I had toplumb the caller `RuntimeComponentInstanceIndex` through a bunch of trampolinesthat didn't previously need it, hence the large diff.Note that I've added a slightly tweaked version of `trap-in-post-return.wast`and left the upstream version disabled in `test-util/src/wast.rs` due to #11683.Fixes #11676.Signed-off-by: Joel Dice * fix test regressionsSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component.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/component.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/component.rs

e8189549 - use a single table per instance for resources, waitables, etc. (#11374)

Tue, 12 Aug 2025 20:34:35 +0000

use a single table per instance for resources, waitables, etc. (#11374)* use a single table per instance for resources, waitables, etc.Per https://github.com/WebAssembly/component-model/pull/513, the spec now putsresources, waitables, waitable sets, subtasks, and error contexts in the sametable per instance. This updates the implementation to match.- Combine the `ResourceTable` and `StateTable` data structures into a single `HandleTable` structure- Rename `ComponentInstance::instance_resource_tables` to `instance_handle_tables`- Remove `ConcurrentState::waitable_tables` and `error_context_tables` in favor of the above- Move various associated functions from `ConcurrentState` to `ComponentInstance` so they can access `instance_resource_tables`While I was doing table-related things, I also updated `concurrent::Table::new`to reserve the zero handle to mean "invalid". This won't affect what the guestsees in any way, but it allows us to use `TableId::new(0)` to invalidatehost-owned handles in e.g. `{Stream,Future}{Reader,Writer}::close`.Fixes #11189Signed-off-by: Joel Dice Re-internalize `ResourceKind` to `mod handle_table`Remove `ResourceKind`Start flattening the representation of `Slot`Internalize `get_mut_handle_by_index`Internalize implementation details such as the representation of slotsto and make methods a bit more targeted in their functionality.Internalize more details of `HandleTable`Don't expose `HandleKind` and of per-function methods for operating onthe various kinds of handles that reside in the table.Flatten the representation of `Slot`There's still some more work to do for host/guest resource handles, butthis helps realize the goal of the previous refactorings in themeantime.* stop using `HandleTable::reps_to_indexes` when delivering eventsPer review feedback, we'd like to get rid of `HandleTable::reps_to_indexes`entirely. This commit doesn't go quite that far, but now we only use it for`error-context` handles. For waitables, which can only be referenced by at mostone guest at a time, we now store the guest handle in `WaitableCommon::handle`and retrieve it from there when delivering an event for that waitable.For `error-context` handles, the spec requirement that we always lower the samehandle for the same `error-context`, combined with the fact that an`error-context` may be referenced by more than one component instance at a time,means we still need some general way to convert a host rep plus component indexinto a handle. Going forward, we could consider either removing that "samehandle" requirement from the spec or consider an alternative implementation(e.g. storing a `HashMap` in the `ErrorContext`host state for keeping track of the handles for each referencing instance.Signed-off-by: Joel Dice * remove `HandleTable::reps_to_indexes`Turns out the spec no longer requires that guests receive the same handle for agiven `error-context` as the one they already have, so we no longer need thisfield -- nor do we need to maintain a per-component-instance reference count.Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component.rs