Changes in store.rs

9661ca85 - Remove some more panics in `concurrent.rs` (#12874)

Mon, 30 Mar 2026 14:18:12 +0000

Remove some more panics in `concurrent.rs` (#12874)Downgrade some panics to `bail_bug!` or `?` where appropriate bypropagating `Result` in a few more locations. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/store.rs

2264f72a - Enable limiting wasip3 resource limits (#12761)

Wed, 11 Mar 2026 20:14:24 +0000

Enable limiting wasip3 resource limits (#12761)* Enable limiting wasip3 resource limitsThis commit adds a new `Store::concurrent_resource_table` method whichenables getting a handle to the underlying `ResourceTable` used by theconcurrent implementation of component-model-async. This can in turn beused to set the max capacity on the table and limit the guest usage ofthe table.Closes #11552* Adjust features* Fix imports List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/store.rs

301dc716 - Fix two security advisories. (#12652)

Tue, 24 Feb 2026 18:23:59 +0000

Fix two security advisories. (#12652)* Fix two security advisories.This commit contains merged fixes for two security advisories inWasmtime:* GHSA-852m-cvvp-9p4w* GHSA-243v-98vx-264hThis introduces new knobs to Wasmtime to limit the scope of resourcesthat WASI implementations will allocate on behalf of guests. Unlikebackports to 41.0.x-and-prior these knobs all have default values whichare considered reasonable for hosts if they don't further tune them. Thefollowing CLI knobs have been added:* `-Smax-resources` - limits the total component-model resources a guest can allocate in a table* `-Shostcall-fuel` - a broad limit which enforces that at most this amount of data will be copied from the guest to the host in any one API call (e.g. `string` values can't be too big, `list` can't be quadratic, etc). This fuel is reset on each host function call.* `-Smax-random-size` - the maximal size of the return value of the `get-random-bytes` and `get-insecure-random-bytes` WASI functions.* `-Smax-http-fields-size` - a limit on the size of `wasi:http` `fields` values to avoid infinitely buffering data within the host.The `http` crate has additionally been updated to avoid a panic whenadding too many headers to a `fields` object.Co-authored-by: Mark Bundschuh Co-authored-by: Pat Hickey Co-authored-by: Joel Dice * CI fixes* Run rustfmt* Fix wasi-common build* Fix tests on 32-bit* Fix nightly test expectationsprtest:full---------Co-authored-by: Mark Bundschuh Co-authored-by: Pat Hickey Co-authored-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/store.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/component/store.rs

7e11f182 - Consolidate component-related store data (#12549)

Mon, 09 Feb 2026 21:02:06 +0000

Consolidate component-related store data (#12549)Instead of having `#[cfg]` within `store.rs` move it all to`component/store.rs` to cut down on `#[cfg]`. It's a bit awkward in someplaces trying to borrow a bunch of fields at once, but it's not the endof the world. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/store.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/component/store.rs

21797bb5 - Refactor how concurrency support is enabled in a `Store` (#12416)

Fri, 23 Jan 2026 22:37:55 +0000

Refactor how concurrency support is enabled in a `Store` (#12416)* Document panics from using CM async machinery when CM async is not enabled* Refactor how concurrency support is enabled in a `Store`This commit is an extension/refactor of #12377 and #12379. Notably thisdecouples the runtime behavior of Wasmtime from enabled/disabledWebAssembly proposals. This enables the `wasmtime serve` subcommand, forexample, to continue to disallow component-model-async by default butcontinue to use `*_concurrent` under the hood.Specifically a new `Config::concurrency_support` knob is added. This isplumbed directly through to `Tunables` and takes over the preexisting`component_model_concurrency` field. This field configures whethertasks/etc are enabled at runtime for component-y things. The defaultvalue of this configuration option is the same as `cfg!(feature ="component-model-async")`, and this field is required ifcomponent-model-async wasm proposals are enabled. It's intended thateventually this'll affect on-by-default wasm features in Wasmtimedepending if the support is compiled in.This results in a subtle shift in behavior where component-model-asyncconcurrency is used by default now because the feature is turned on bydefault, even though the wasm features are off-by-default. This requiredadjusting a few indices expected in runtime tests due to tasks/threadsbeing allocated in index spaces.Finally, this additionally denies access at runtime to`Linker::*_concurrent` when concurrent support is disabled as otherwisethe various runtime data structures won't be initialized and panics willhappen.Closes #12393* Add a `-Wconcurrency-support` CLI flagUsed to update disas tests to show that, when disabled, old codegenquality is preserved* Ungate `Config` flag* Review comments---------Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/store.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/component/store.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/component/store.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/component/store.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/component/store.rs

8aefdcc0 - Delete `StoreOpaque::traitobj_mut` (#11444)

Mon, 18 Aug 2025 22:43:27 +0000

Delete `StoreOpaque::traitobj_mut` (#11444)* Delete `StoreOpaque::traitobj_mut`This was a fundamentally unsound function because it is widening amutable borrow to encompass more than it originally contained. Removalof its usage falls into a few buckets here:* Many instances of `store.0.traitobj_mut()` were starting from a `&mut StoreInner`, going to `&mut StoreOpaque`, then going back to `&mut dyn VMStore`. These are replaced with `store.0` as `&mut StoreInner` directly coerces into `&mut dyn VMStore`.* Some fiber-related helpers were updated to take any store-opaque-thing which encapsulates the ability to start/resume a borrow with a part of the store, but you only get that part of the store during the fiber itself. This means there's no widening necessary.* Some methods previously taking `&mut StoreOpaque` are now appropriately widened to `&mut dyn VMStore`.This all enables full deletion of this function which preventsaccidentally ever tripping over its unsound-ness.* Fix configured build* Another fix for a configured build* Fix a warning* Don't hold `VMStore` live over await points* Review comments* Move `AsStoreOpaque` to `store.rs` and use it in GC* Fix configured build* Switch lint annotation List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/store.rs

b4475438 - refactor `{Stream,Future}|{Reader,Writer}` APIs and internals (#11325)

Wed, 30 Jul 2025 16:40:41 +0000

refactor `{Stream,Future}|{Reader,Writer}` APIs and internals (#11325)* refactor `{Stream,Future}|{Reader,Writer}` APIs and internalsThis makes a several changes to how `{Stream,Future}|{Reader,Writer}` work tomake them more efficient and, in some ways, more ergonomic:- The background tasks have been removed, allowing reads and writes to complete without task context switching. We now only allocate and use oneshot channels lazily when the other end is not yet ready; this improves real world performance benchmarks (e.g. wasi-http request handling) considerably.- Instances of `{Stream,Future}Reader` can now be lifted and lowered directly; no need for `Host{Stream,Future}` anymore.- The type parameter for `Stream{Reader,Writer}` no longer refers to the buffer type -- just the payload type (i.e. `StreamReader` instead of `StreamReader>`), meaning any buffer type may be used for a given read or write operation. This also means the compiler needs help with type inference less often when calling `Instance::stream`.- Instances of `{Stream,Future}|{Reader,Writer}` now require access to the store in order to be disposed of properly. I've added RAII wrapper structs (`WithAccessor[AndValue]`) to help with this, and also updated `Store::drop` and `Instance::run_concurrent` to ensure the store thread-local is set when dropping futures closing over `&Accessor`s.- In order to ensure that resources containing `{Stream,Future}|{Reader,Writer}` instances are disposed of properly, I've added `LinkerInstance::resource_concurrent` and have updated `wasmtime-wit-bindgen` to use it. This gives resource drop functions access to a `StoreContextMut` via an `Accessor`, allowing the stream and future handles to be disposed of. - In order to make this work, I had to change `Accessor::instance` from a `Instance` to an `Option`, which is awkward but temporary since we're planning to remove `Accessor::instance` entirely once we've moved concurrent state from `ComponentInstance` to `Store`.That problem of disposal is definitely the most awkward part of all this. Insimple cases, it's easy enough to ensure that read and write handles aredisposed of properly, but both `wasmtime-wasi` and `wasmtime-wasi-http` havesome pretty complicated functions where handles are passed between tasks and/orstored inside resources, so it can be tricky to ensure proper disposal on allcode paths. I'm open to ideas for improving this, but I suspect we'll need newRust language features (e.g. linear types) to make it truly ergonomic, robust,and efficient.While testing the above, I discovered an issue with `Instance::poll_until` suchthat it would prematurely give up and return a "deadlock" trap error, believingthat there was no further work to do, even though the future passed to it wasready to resolve the next time it was polled. I've fixed this by polling it onelast time and only trapping if it returns pending.Note that I've moved a few associated functions from `ConcurrentState` to`Instance` (e.g. `guest_drop_writable` and others) since they now need access tothe store; they're unchanged otherwise. Apologies for the diff noise.Finally, I've tweaked how `wasmtime serve` to poll the guest for content beforehanding the response to Hyper, which helps performance by ensuring the firstcontent chunk can be sent with the same TCP packet as the beginning of theresponse.Signed-off-by: Joel Dice fix wasi p3 build and test failuresSigned-off-by: Joel Dice use `ManuallyDrop` instead of `Option` in `Dropper`This allows us to drop its `value` field in-place, i.e. without moving it,thereby upholding the `Pin` guarantee.Signed-off-by: Joel Dice address review comments- Remove `DropWithStoreAndValue` and friends; go back to taking a `fn() -> T` parameter in `Instance::future` instead- Make `DropWithStore::drop[_with]` take `&mut self` instead of `self`- Make `WithAccessor` and `DropWithStore` private - Instead, I've added public `Guarded{Stream,Future}{Reader,Writer}` types for RAII - and also `{Stream,Future}{Reader,Writer}::close[_with]` methods- Use RAII in `FutureReader::read` and `FutureWriter::write` to ensure handles are dropped if the `Future` is droppedSigned-off-by: Joel Dice * lower host stream/future writes in background taskThis avoids unsoundness due to guest realloc calls while there are host embedderframes on the stack.Signed-off-by: Joel Dice * fix `tcp.rs` regressionsSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/store.rs

2b832281 - Gut `vm::Export` to mostly be `crate::Extern` (#11229)

Mon, 14 Jul 2025 21:05:01 +0000

Gut `vm::Export` to mostly be `crate::Extern` (#11229)* Remove `Table::from_wasmtime_table`This commit removes the unsafe function `Table::from_wasmtime_table`.This goes a bit further and removes `ExportTable` entirely as well whichmeans that table lookup on a `vm::Instance` directly returns a`wasmtime::Table` without any need to translate back-and-forth.* Remove `Tag::from_wasmtime_tag`Like the previous commit, but for tags.* Remove `Global::from_wasmtime_global`Like the previous commit, but for globals.* Remove `Memory::from_wasmtime_memory`Like the previous commit, but for memories.* Remove `Func::from_wasmtime_function`Like previous commits, but for functions.* Fix lints* Fill out missing safety comment* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/store.rs

fa70f025 - implement Component Model async ABI (#11127)

Fri, 11 Jul 2025 21:06:04 +0000

implement Component Model async ABI (#11127)* implement Component Model async ABIThis commit replaces the stub functions and types in`wasmtime::runtime::component::concurrent` and its submodules with the workingimplementation developed in the `wasip3-prototyping` repo. For ease of review,it does not include any new tests; I'll add those in a follow-up commit.Note that this builds on #11123; only the most recent commit is new.Signed-off-by: Joel Dice * clear params pointer in `call_async` when future is droppedThis ensures that the closure we pass to `prepare_call` will never see a stalepointer.Note that this could potentially be made more efficient; I'm starting with asimple solution, and we can refine from there.Signed-off-by: Joel Dice * Remove unsafety from accessing concurrent async state* Remove a dead variant when async is disabled* Add tests for `tls.rs` unsafe code* Refactor `AbortHandle`* Don't close over the entire future in the `AbortHandle`, instead change it to just the bare minimum state to manage aborts.* Move aborting logic into a helper `AbortHandle::run` function which handles the is-this-aborted-check internally.* Refactor some logic around spawns how `AbortHandle` is managed/created.* Internalize some functions/types* add FIXME comment to `states.rs`Signed-off-by: Joel Dice * reference issue 11190 in `table.rs` TODOSigned-off-by: Joel Dice * switch `use` directives to conventional syntaxSigned-off-by: Joel Dice * remove redundant accessor methodsSigned-off-by: Joel Dice * reference issue 11191 in `yield` TODO commentsSigned-off-by: Joel Dice * replace `dummy_waker` with `Waker::noop`Signed-off-by: Joel Dice * remove obsolete `AsyncState::spawned_tasks` fieldSigned-off-by: Joel Dice * only call post-return automatically for `call_concurrent`This restores the original behavior of requiring explicit post-return calls for`call[_async]` invocations.Signed-off-by: Joel Dice * Favor function arguments before closures* Simplify `watch` a bitMostly move unnecessary state out of the `Arc`.* fix task handle leaks and add test coverageWe weren't always disposing of guest or host task handles once they becameunreachable. This adds a couple of hidden methods which integration tests mayuse to guard against use-after-delete, double-delete, and leak bugs regardingwaitable handles. It also tightens up handle management in `concurrent.rs` toensure those tests pass.Signed-off-by: Joel Dice * Encapsulate type erasure in stream buffersDon't rely on all buffers to handle `TypeId` and assertions and such,instead have a helper type which is the one location of the assertionsand everything else can stay typed.* Remove some methods ending in underscores* Refactor unsafety in `buffers.rs`Mostly move away from raw pointers and instead use utilities like`&[MaybeUninit]`. Also make `WriteBuffer` an `unsafe` trait afterabsorbing the `TakeBuffer` trait. Update all safety-related commentshere and there too.* remove task on drop in `TypedFunc::call_async`This avoids the need for an `Arc`.Signed-off-by: Joel Dice * remove obsolete clause from `FutureReader::read` docsSigned-off-by: Joel Dice * unhide and expand docs for `WriteBuffer` and `ReadBuffer`Signed-off-by: Joel Dice * add optional `component-model-async-bytes` featureThis gates interop with the `bytes` crate, making it optional and non-default.Signed-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/component/store.rs

421136d0 - generalize async fiber abstraction (#11114)

Thu, 26 Jun 2025 21:52:21 +0000

generalize async fiber abstraction (#11114)* generalize async fiber abstractionAs part of the work implementing the new Component Model async ABI in the`wasip3-prototyping` repo, I've generalized the `FiberFuture` abstraction in`wasmtime::runtime::store::async_` to support fibers which can either retainexclusive access to the store across suspend points or release it. The latterallows the store to be used by the `component-model-async` event loop and/orother fibers to run before the original fiber resumes, which is the key toallowing multiple fibers to run concurrently, passing control of the store backand forth.In the case of Pulley, the above generalization means we also need to give eachfiber its own `Interpreter` so that multiple concurrent fibers don't clobbereach other's state.Concretely, this moves a lot of the code out of `async_.rs` and into a new`fiber.rs` submodule which will be shared with the `component-model-async`implementation.This also pulls in a new `StoreToken` utility which has been useful in`wasip3-prototyping` to safely convert from a `&mut dyn VMStore` to a`StoreContextMut<'a, T>` when we previously witnessed a conversion in the otherdirection.Note that I've added a `'static` bound to the `VMStore` trait, which simplifiesuse of `&mut dyn VMStore`, avoiding thorny lifetime issues.Signed-off-by: Joel Dice * address review feedbackSigned-off-by: Joel Dice * fix miri-flagged stacked borrow violationAs part of my earlier effort to unify the fiber abstractions in the `wasmtime`crate, I changed a `*mut StoreFiber` field to a `&mut StoreFiber`, not realizingthat it resulted in a mutable alias at runtime and thus undefined behavior.Miri caught it, fortunately.Signed-off-by: Joel Dice * remove unneeded `Send` boundsSigned-off-by: Joel Dice * address more review feedbackMain changes:- Make `resume_fiber[_raw]` take a `&mut StoreOpaque` parameter to make its unsafe internals easier to reason about, safety-wise.- Panic if `StoreFiber::drop` is called on an in-progress fiber without having called `StoreFiber::dispose` to gracefully end it first.- (Re)introduce `FiberFuture`, which closes over a `&mut StoreOpaque` and uses it to call `StoreFiber::dispose` on drop.This will require a few more changes to make it usable by `concurrent.rs`, butI'll save those changes for a later PR.Signed-off-by: Joel Dice * address more review feedbackSigned-off-by: Joel Dice * update `impl Send For StoreFiber` commentSigned-off-by: Joel Dice * Remove currently-extraneous `Result<()>` from fibersMay be needed for concurrent bits, but for now not necessary.* Use safe pointers instead of raw pointersIt's predicted Miri won't like this, but for now in-repo it's ok with it.* Fold more responsibility into `resume_fiber_raw`Remove the need for the function entirely and replace it with`resume_fiber`.* Remove channels from async fibersCan use stack-based closures/results to transmit the result instead ofneeding a channel.* Fold `on_fiber_raw` directly into `on_fiber`The `on_fiber` function is small enough it should be possible to do so.* Don't use `Option` in `FiberFuture`Leave the fiber non-optional at-rest so it's always available for thedestructor.* Fold `suspend` functions togetherSmall shims, not otherwise public at this time, so remove a layer ofindirection.* Move stack limit management to `FiberResumeState`Helps remove some raw pointers that are held for a long time within`AsyncCx`* add some doc comments to `fiber.rs`Signed-off-by: Joel Dice * update `fiber.rs` and friends to match CM async requirementsThis adds a `resolve_or_release` function, which `Instance::resume_fiber` willuse when current `concurrent.rs` stub is replaced by a real implementation.Signed-off-by: Joel Dice * fix non-component-model-async build warningsSigned-off-by: Joel Dice * make `resume_fiber` private in `fiber.rs`Signed-off-by: Joel Dice * Shrink `PollContext` stateMove management of the async guard range elsewhere to the normalsave/restore area.* Refactor `AsyncCx`, reduce `unsafe`* Remove the `AsyncCx` type from Wasmtime as it's inherently `unsafe` to use, instead bundle operations directly on a `Store*` reference.* Don't retain pointers-to-pointers within the roughly-equivalent `BlockingContext` created in this PR. Instead when a blocking context is created "take" the metadata from the store to assert exclusive ownership of the pointers.* Refactor how `&mut Context<'_>` is passed around, namely thread it through fiber parameters to model resumption as registering a new context to poll with.* Remove `PollContext` in favor of directly storing a pointer as it's now mostly an empty structure.* Minor refactorings to make things more future-refactorable and/or clear in a few places.* Refactor management of the "current suspend" and "current future context" pointers. These are now null'd out on resumption and asserted null on suspension.* Remove the need for a generic `Reset` structure in the fiber bits as it's a pretty dangerous structure to have in general.The end result of this refactoring is that all usage of `block_on` isnow safe and additionally many of the internals of the implementationare safer than they were before* Adjust some lint attributes* Make manipulation of `AsyncState` safeNo need for raw pointers with recent refactorings.* Fix dead code warning* More dead code warnings* Cut down on raw pointers in fiber.rs* Move executor save/restore to normal fiber state save/restore* Bikeshed a method name* update comment in make_fiberSigned-off-by: Joel Dice * fix machports buildSigned-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/component/store.rs

7e28c254 - Use `Pin<&mut ComponentInstance>` (#11042)

Sat, 14 Jun 2025 01:32:31 +0000

Use `Pin<&mut ComponentInstance>` (#11042)This commit is the continuation of #10943 for component instances. Theallocation/vmctx infrastructure was additionally refactored to be shared forboth core and component instances since they behave the exact same way anyway.This further enables sharing various methods like `vmctx_plus_offset` which arepretty unsafe internally.Like #10943 this necessitated removal of `Index` implementations because`IndexMut` is not compatible with the returned type being `Pin<&mut T>`so they were replaced by inherent `get` and `get_mut` methods on thecomponent instance id type.Closes #10933 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/store.rs

47e90882 - Start reducing unsafety of `ComponentInstance` (#10934)

Thu, 05 Jun 2025 21:44:02 +0000

Start reducing unsafety of `ComponentInstance` (#10934)Work recently in the wasip3-prototyping repository has focused onreducing the amount of `unsafe` code and improving internal abstractionsto facilitate this. One major thrust that's manifested in is the removalof the usage of `*mut ComponentInstance` where possible and insteadusing an index to safely borrow from the store to get the entireinstance. This commit does not fully realize this vision just yet butlays some groundwork leading up to this.This commit specifically removes the `*mut ComponentInstance` pointersin lift/lower contexts in favor of directly storing a`wasmtime::component::Instance`. When the raw `ComponentInstance` isneeded it's acquired from the `StoreOpaque` in a safe fashion thatborrows the entire store for the duration of the returned borrow. Thisin turn required pushing instances into the store earlier duringinstantiation because during instantiation an instance could call out tohost APIs which do lifts/lowers.There's still more work to be done to plumb this fully into libcalls andhost function invocations but I wanted to upstream the wasip3 workpiecemeal a chunk at a time. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/store.rs

5603ee7b - Change component/instance maps to `PrimaryMap` (#10916)

Tue, 03 Jun 2025 22:11:29 +0000

Change component/instance maps to `PrimaryMap` (#10916)* Change component/instance maps to `PrimaryMap`This switches to using typed keys for these maps to be more idiomaticwith the rest of Wasmtime and this has the additional benefit ofcompressing indices to 32-bits instead of the previouspointer-sized-bits.* Fix an unused import List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/store.rs

e33836c0 - Refactor the representation of component::Func (#10914)

Tue, 03 Jun 2025 21:23:21 +0000

Refactor the representation of component::Func (#10914)* Expand on FIXME commentsIn case it takes awhile to get to them...* Remove `FuncData::types`This can always be inferred from the instance itself.* Add an `ExportIndex` to `FuncData`This will soon be used to remove most other fields, but for now justhave it hanging out there.* Remove `FuncData::component_instance` field* Remove `FuncData::post_return`* Remove `FuncData::ty`* Remove `FuncData::export`* Remove `FuncData::options`* Remove `FuncData::post_return_arg`This field was moved to `ComponentInstance` as the stateful storage ofthe last function return value.* Refactor the representation of `component::Func`This commit updates the implementation of `component::Func` to beindex-based like all other exported items are now in Wasmtime. Thisnecessitated a new `StoreComponentInstanceId` abstraction similar to`StoreInstanceId`. Additionally the `component_instance_replace`function was entirely removed as it's no longer necessary. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/store.rs