Changes in instance.rs

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

Mon, 30 Mar 2026 18:35:31 +0000

Handle OOM in the rest of Wasmtime's non-component, -async, -compilation APIs (#12858)* Handle OOM in more places in the public APIA bunch of random places:* Add: `Trap::try_new` to handle OOM while creating traps* Use: `TryVec` inside `Func::call_impl_do_call` and `wasm_val_raw_storage` to hold the args and rets* Add: `Instance::try_exports` for iterating over an instance's exports while handling OOM* `Linker:try_get`, like `Linker::get` but handling OOM* `Linker:try_get_by_import`, like `Linker::get_by_import` but handling OOM* Use `try_new` to box things in `SharedMemory::new`* Use `TryVec` instead of `Vec` in our dynamic tables* Add OOM tests for most of Wasmtime's public APIExcludes component-, async-, and compilation-related APIs.* address review feedback* fix test compilation* fix c-api List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/instance.rs

282a1814 - Use `TryPrimaryMap` in an instance's `OwnedImports` (#12847)

Thu, 26 Mar 2026 17:45:48 +0000

Use `TryPrimaryMap` in an instance's `OwnedImports` (#12847) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/instance.rs

da093747 - Relax panics in async/futures to traps/errors (#12688)

Mon, 02 Mar 2026 21:26:40 +0000

Relax panics in async/futures to traps/errors (#12688)* Relax panics in async/futures to traps/errorsThis commit is an admittance that I don't believe we're going to getto a point where we are confident enough in the fuzzing ofcomponent-model-async such that we could confidently say we'reexercising the vast majority of possible panics. Development ofcomponent-model-async has shown a steady trickle of panics over thecourse of the development of the feature, and this trend has beenpersistent over time as well.An attempt was made in #12119 to add a fuzzer dedicated to async eventsbut that didn't actually find anything in development and it has misseda number of panics present before and discovered after its introduction.Overall I do not know how to improve the fuzzer to the point that itwould find pretty much all of the existing async-related panics overtime.To help address this concern of the `concurrent.rs` implementation thiscommit goes through and replaces things like `unwrap()`, `assert!`,`panic!`, and `unreachable!` with an error-producing form. The benefitof this is that a bug in the implementation is less likely to result ina panic and instead just results in a non-spec-compliant trap. Thedownside of doing this though is that it can become unclear what errorsare "first class traps", or expected to be guest reachable, and whichare expected to be bugs in Wasmtime. To help address this I've performeda few refactorings here as well.* Some traps previously present as error strings are now promoted to using `Trap::Foo` instead. This has some refactoring of the Rust/C side as well to make it easier to define new variants. Tests were additionally added for any trap messages that weren't previously tested as being reachable.* A new `bail_bug!` macro was added (internally) for Wasmtime. This is coupled with a concrete `WasmtimeBug` error type (exported as `wasmtime::WasmtimeBug`). The intention is that `bail!` continues to be "here's a string and I'm a bit too lazy to make a concrete error" while `bail_bug!` indicates "this is a bug in wasmtime please report this if you see it".The rough vision is that if an error condition is reached, and the systemis not broken in such a way that panicking is required, then `bail_bug!`can be used to indicate a bug in Wasmtime as opposed to panicking. Thisreduces the real-world impact of hitting these scenarios by downgrading aCVE-worthy `panic!` into a bug-worthy non-spec-compliant trap. Not allpanics are able to be transitioned to this as some are load bearing froma safety perspective or similar (or indicate something equally broken),but the vast majority of cases are suitable for "return a trap, lockdown the store, and let destructors take care of everything else".This change additionally has resulted in API changes for `FutureReader`and `StreamReader`. For example creation of these types now returns a`Result` for when the `ResourceTable` is full, for example, instead ofpanicking.* Fix CI build* Translate `WasmtimeBug` to panics in debug mode* Review comments* Refactor some stream methods for fewer panics List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/instance.rs

b90b8965 - Debugging: apply single-stepping patches to modules instantiated after setting changes. (#12663)

Wed, 25 Feb 2026 00:01:48 +0000

Debugging: apply single-stepping patches to modules instantiated after setting changes. (#12663)We currently do a store-wide state-change on all registered moduleswhen the "single stepping" flag changes, patching in or out allbreakpoints. However, this design didn't account for modulesregistered with the store *after* single-stepping is enabled (and newmodules may be registered any time an instantiation occurs). Inparticular this is problematic when a debugger, e.g., sets thesingle-step flag right at the beginning of execution of a "host mainfunction" that calls Wasm, before the main instantiation occurs.This PR threads through the breakpoint state in the registration path,with the narrow waist at `ModuleRegistry::register` which is the onlyplace where modules are added to the `LoadedCode`. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/instance.rs

1f16b28f - Refactor `String` usage in `wasmtime_environ::Module` (#12565)

Thu, 12 Feb 2026 21:27:05 +0000

Refactor `String` usage in `wasmtime_environ::Module` (#12565)* Refactor `String` usage in `wasmtime_environ::Module`Do not hold regular `String`s; instead use our own OOM-handling`wasmtime_core::alloc::String` or, even better, an interned `Atom` from the`StringPool`.Also avoid `IndexMap`, as it doesn't handle OOMs.* Use OOM-handling `IndexMap` in `wasmtime_environ::Module`* review feedback List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/instance.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/instance.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/instance.rs

98499653 - Move `ResourceTables` constructors to `StoreOpaque` (#12546)

Mon, 09 Feb 2026 20:03:18 +0000

Move `ResourceTables` constructors to `StoreOpaque` (#12546)* Move `ResourceTables` constructors to `StoreOpaque`This is intended to consolidate where they're constructed, provideaccess to the host data at all times, and pave the way for a futurerefactoring here to touch fewer lines.* Fix a cfg List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/instance.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/component/instance.rs

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

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

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

b271e452 - consistently create thread and task when entering component instance (#12379)

Fri, 23 Jan 2026 17:51:19 +0000

consistently create thread and task when entering component instance (#12379)* consistently create thread and task when entering component instancePreviously, we weren't creating a new thread or task in all cases when enteringa component instance, even when component model async features were enabled. Inparticular, entering an instance via a sync-to-sync, guest-to-guest adapter, via`Linker::instantiate[_async]`, or via `[Typed]Func::call` all skipped creating athread or task, creating panics and/or instance mismatches in certain cases.This commit addresses all those cases and also adds assertions to all CM asyncintrinsics to verify that the caller instance matches the most-recently-pushedtask. Note that we still skip pushing and popping threads and tasks if no CMasync features are enabled in the `Config`.In order to populate the `GuestTask::instance` field for tasks created as partof `Linker::instantiate[_async]` calls, I had to add a`RuntimeComponentInstanceIndex` field to `GlobalInitializer::InstantiateModule`and friends so it would be available when needed.While testing this, I uncovered and fixed a couple of related issues:- We weren't checking the `may_leave` flag when guest-to-guest calling a resource destructor- We weren't checking whether a subtask was ready to delete (e.g. that no threads were still running) before attempting to delete it while deleting its supertask* fix warnings when component-model-async feature disabled* address review feedback* push a task when calling a resource dtor host-to-guest* add tests which call `thread.index` from realloc and post-return functions...and assert that the indexes match as expected.Getting the post-return test to pass required moving the call to`StoreOpaque::exit_sync_call` to after the post-return function is called. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/instance.rs

cc8d04f4 - Remove need for explicit `Config::async_support` knob (#12371)

Fri, 23 Jan 2026 02:46:45 +0000

Remove need for explicit `Config::async_support` knob (#12371)* Refactor component model host function definitionsPush the `async`-ness down one layer.* Remove need for explicit `Config::async_support` knobThis commit is an attempt to step towards reconciling "old async" and"new async" in Wasmtime. The old async style is the original asyncsupport in Wasmtime with `call_async`, `func_wrap_async`, etc, where themain property is that the store is "locked" during an async operation.Put another way, a store can only execute at most one async operation ata time. This is in contrast to "new async" support in Wasmtime with thecomponent-model-async (WASIp3) support, where stores can have more thanone async operation in flight at once.This commit does not fully reconcile these differences, but it doesremove one hurdle along the way: `Config::async_support`. Since thebeginning of Wasmtime this configuration knob has existed to explicitlydemarcate a config/engine/store as "this thing requires `async` stuffinternally." This has started to make less and less sense over timewhere the line between sync and async has become more murky with WASIp3where the two worlds comingle. The goal of this commit is to deprecate`Config::async_support` and make the function not actually do anything.In isolation this can't simply be done, however, because there are manyload-bearing aspects of Wasmtime that rely on this `async_support` knob.For example once epochs + yielding are enabled it's required that allWasm is executed on a fiber lest it hit an epoch and not know how toyield. That means that this commit is not a simple removal of`async_support` but instead a refactoring/rearchitecting of how async isused internally within Wasmtime. The high-level ideas within Wasmtimenow are:* A `Store` has a "requires async" boolean stored within it.* All configuration options which end up requiring async, such as yielding with epochs, turn this boolean on.* Creation of host functions which use async (e.g. `func_wrap_{async,concurrent}`) will also turn this option on.* Synchronous API entrypoints into Wasmtime ensure that this boolean is disabled.* Asynchronous APIs are usable at any time.This means that the concept of an async store vs a sync store is nowgone. All stores are equally capable of executing sync/async, and thechange now is that dynamically some stores will require that async isused with certain configuration. Additionally all panicking conditionsaround `async_support` have been converted to errors instead. Allrelevant APIs already returned an error and things are murky enough nowthat it's not necessarily trivial to get this right at the embedderlevel. In the interest of avoiding panics all detected async mismatchesare now first-class `wasmtime::Error` values.The end result of this commit is that `Config::async_support` is adeprecated `#[doc(hidden)]` function that does nothing. While manyinternal changes happened as well as having new tests for all this sortof behavior this is not expected to have a great impact on externalconsumers. In general a deletion of `async_support(true)` is in theoryall that's required. This is intended to make it easier to think aboutasync/sync/etc in the future with WASIp3 and eventually reconcile`func_wrap_async` and `func_wrap_concurrent` for example. That's leftfor future refactorings however.prtest:full* Review comments* Fix CI failures List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/instance.rs

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

Fri, 09 Jan 2026 19:23:56 +0000

Do not re-export `anyhow!` in the `wasmtime::prelude` (#12298)We are trying to move to `format_err!` instead. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/instance.rs

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

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

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

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

Wed, 03 Dec 2025 01:18:00 +0000

Debug: create private code memories per store when debugging is enabled. (#12051)* Debug: create private code memories per store when debugging is enabled.This will allow patching code to implement e.g. breakpoints. (That is,for now the copies are redundant, but soon they will not be.)This change follows the discussion [here] and offline to define a fewtypes that better encapsulate the distinction we want to enforce.Basically, there is almost never a bare `CodeMemory`; they are alwayswrapped in an `EngineCode` or `StoreCode`, the latter being a per-storeinstance of the former. Accessors are moved to the relevant place sothat, for example, one cannot get a pointer to a Wasm function's bodywithout being in the context of a `Store` where the containing modulehas been registered. The registry then returns a `ModuleWithCode` thatboxes up a `Module` reference and `StoreCode` together for cases wherewe need both the metadata from the module and the raw code to derivesomething.The only case where we return raw code pointers to the `EngineCode`directly have to do with Wasm-to-array trampolines: in some cases, e.g.`InstancePre` pre-creating data structures with references to hostfunctions, it breaks our expected performance characteristics to makethe function pointers store-specific. This is fine as long as theWasm-to-array trampolines never bake in direct calls to Wasm functions;the strong invariant is that Wasm functions never execute from`EngineCode` directly. Some parts of the component runtime would alsohave to be substantially refactored if we wanted to do away with thisexception.The per-`Store` module registry is substantially refactored in this PR.I got rid of the modules-without-code distinction (the case where amodule only has trampolines and no defined functions still works fine),and organized the BTreeMaps to key on start address rather than endaddress, which I find a little more intuitive (one then queries with thedual to the range -- 0-up-to-PC and last entry found).[here]: https://github.com/bytecodealliance/wasmtime/pull/12051#pullrequestreview-3493711812* Review feedback: do not assume a reasonable code alignment; error when it cannot be known* Review feedback: fail properly in profiler when we are cloning code* Fix guest-profiler C API.* Review feedback: make private-code representation impossible in non-debugging-support builds.* Add TODO comment referencing issue for cloning only .text.* clang-format* Review feedback: add back Component::image_range.* Review feedback: error on registering profiling metadata when debug is enabled.* rustfmt* Remove early bail on profiling-data registration when debugging is enabled: this always happens so we cannot error out. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/instance.rs

1fcd0933 - Prevent using shared memories with `Memory` (#12022)

Tue, 11 Nov 2025 18:06:22 +0000

Prevent using shared memories with `Memory` (#12022)* Prevent using shared memories with `Memory`This commit fixes a few issues where it was possible to represent a wasmshared linear memory with the `wasmtime::Memory` type. This is not soundbecause `wasmtime::Memory` provides safe Rust access to the bytes wherethat is not possible with wasm shared memories. Shared memories in Rustmust be represented by `SharedMemory`, not `wasmtime::Memory`.Specifically this commit prevents two vectors of this happening:1. `Memory::new` now requires that the memory type specified is non-shared. Instead `SharedMemory::new` must be used instead.2. Core dumps now skip over shared memories when iterating over all memories in the store. Supporting shared memories is left to a future feature request for now.* CI fixes List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/instance.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/component/instance.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/component/instance.rs