Changes in memory.rs

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

Mon, 30 Mar 2026 15:02:12 +0000

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

d2dee5dd - Handle OOM in `{Func,Memory,Table,Global}::new` and when calling an instance's exported function (#12855)

Fri, 27 Mar 2026 16:54:22 +0000

Handle OOM in `{Func,Memory,Table,Global}::new` and when calling an instance's exported function (#12855)* Use `try_new` for `Box` in `DefaultMemoryCreator`* Use `TryPrimaryMap` for `host_globals` in `Store`* Add `Func::try_wrap` and use `try_new` for `Box`Add `Func::try_wrap` as a fallible version of `Func::wrap` that returns an erroron out-of-memory instead of panicking. `Func::wrap` now delegates to `try_wrap`.Also use `try_new::>` instead of `Box::new` for `HostFunc`.* Use `bumpalo`'s `try_alloc` for `FuncRefs`* Use `try_new` for `Arc` in "trampoline" code* Test that we handle OOM in `{Func,Memory,Table,Global}::new` and when calling an instance's exported function* cargo fmt List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs

82ebbd5d - Use explicit boxing for InstanceAllocator async methods (#12849)

Thu, 26 Mar 2026 19:23:42 +0000

Use explicit boxing for InstanceAllocator async methods (#12849)Change `allocate_memory` and `allocate_table` in the `InstanceAllocator` traitfrom `async fn`s to regular `fn`s that return `Result>>,OutOfMemory>`.This avoids the implicit `Box::new` allocation that `#[async_trait]` generateswhen calling these methods through `dyn InstanceAllocator`, which would panic onOOM instead of returning an error. Now the boxing is done explicitly via`try_new::>` which returns `Err(OutOfMemory)` on allocation failure. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs

9c17fed6 - Use OOM-handling `PrimaryMap` in `wasmtime_environ::Module` (#12606)

Wed, 18 Feb 2026 16:22:28 +0000

Use OOM-handling `PrimaryMap` in `wasmtime_environ::Module` (#12606) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.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/trampoline/memory.rs

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

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

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

5245e1f8 - Remove `AllCallFunc` (#11694)

Fri, 12 Sep 2025 23:36:30 +0000

Remove `AllCallFunc` (#11694)* Remove `AllCallFunc`And add `FuncKeyKind` and `FuncKeyNamespace` types.Split out from https://github.com/bytecodealliance/wasmtime/pull/11630* fix warning and disriminant gap* add module arg to `Module::new()` calls in tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs

155ea7fc - Remove unsoundness of widening store borrows (#11481)

Thu, 21 Aug 2025 01:24:33 +0000

Remove unsoundness of widening store borrows (#11481)* Remove unsoundness of widening store borrowsThis commit removes preexisting unsoundness in Wasmtime where a`&mut StoreOpaque` borrow was "widened" into encompassing the limiter onthe `T` in `StoreInner`, for example, by using the self-pointerlocated in an instance or the store. This fix is done by threading`&mut StoreOpaque` as a parameter separately from a`StoreResourceLimiter`. This means that various callers now take a new`Option<&mut StoreResourceLimiter<'_>>` parameter in various locations.Closes #11409* Fix gc-less build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs

e1f50aad - Make table/memory creation async functions (#11470)

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

Make table/memory creation async functions (#11470)* Make core instance allocation an `async` functionThis commit is a step in preparation for #11430, notably core instanceallocation, or `StoreOpaque::allocate_instance` is now an `async fn`.This function does not actually use the `async`-ness just yet so it's anoop from that point of view, but this propagates outwards to enoughlocations that I wanted to split this off to make future changes moredigestable.Notably some creation functions here such as making an `Instance`,`Table`, or `Memory` are refactored internally to use this new `async`function. Annotations of `assert_ready` or `one_poll` are used asappropriate as well.For reference this commit was benchmarked with our `instantiation.rs`benchmark in the pooling allocator and shows no changes relative to theoriginal baseline from before-`async`-PRs.* Make table/memory creation `async` functionsThis commit is a large-ish refactor which is made possible by the manyprevious refactorings to internals w.r.t. async-in-Wasmtime. The endgoal of this change is that table and memory allocation are both `async`functions. Achieving this, however, required some refactoring to enableit to work:* To work with `Send` neither function can close over `dyn VMStore`. This required changing their `Option<&mut dyn VMStore>` arugment to `Option<&mut StoreResourceLimiter<'_>>`* Somehow a `StoreResourceLimiter` needed to be acquired from an `InstanceAllocationRequest`. Previously the store was stored here as an unsafe raw pointer, but I've refactored this now so `InstanceAllocationRequest` directly stores `&StoreOpaque` and `Option<&mut StoreResourceLimiter>` meaning it's trivial to acquire them. This additionally means no more `unsafe` access of the store during instance allocation (yay!).* Now-redundant fields of `InstanceAllocationRequest` were removed since they can be safely inferred from `&StoreOpaque`. For example passing around `&Tunables` is now all gone.* Methods upwards from table/memory allocation to the `InstanceAllocator` trait needed to be made `async`. This includes new `#[async_trait]` methods for example.* `StoreOpaque::ensure_gc_store` is now an `async` function. This internally carries a new `unsafe` block carried over from before with the raw point passed around in `InstanceAllocationRequest`. A future PR will delete this `unsafe` block, it's just temporary.I attempted a few times to split this PR up into separate commits buteverything is relatively intertwined here so this is the smallest"atomic" unit I could manage to land these changes and refactorings.* Shuffle `async-trait` dep* Fix configured build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs

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

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

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

0f457fad - Raise `unsafe_op_in_unsafe_fn` further in Wasmtime (#11322)

Fri, 25 Jul 2025 18:22:03 +0000

Raise `unsafe_op_in_unsafe_fn` further in Wasmtime (#11322)* Raise `unsafe_op_in_unsafe_fn` further in WasmtimeNow it's at `wasmtime::runtime`, not just `wasmtime::runtime::vm`.* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs

88079b4f - Make table/memory allocation functions safe (#11320)

Thu, 24 Jul 2025 20:25:21 +0000

Make table/memory allocation functions safe (#11320)These were previously marked as `unsafe` trait methods with arequirement that the memory/table shape must be validated ahead of time.Neither the ondemand nor pooling allocator actually has an unsafecontract to uphold with respect to this and both may assert/rejectnon-validated shapes but memory unsafety won't happen as a result.Consequently these functions are made safe.Instance allocation functions are adjusted to reflect how thecorrectness of `imports` is required for the functions to be safe. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs

046a51ca - Avoid cloning and dropping `Arc`s in `LocalMemory::vmmemory` (#11148)

Fri, 27 Jun 2025 18:51:03 +0000

Avoid cloning and dropping `Arc`s in `LocalMemory::vmmemory` (#11148)* Avoid cloning and dropping `Arc`s in `LocalMemory::vmmemory`Getting the base pointer from the underlying `dyn RuntimeLinearMemory` involvedgetting a `MemoryBase` which is potentially an `MmapOffset` which itselfcontains an `Arc`, and we would then call `base.as_non_null()` to turnthis into a raw pointer, and then we would drop the `MemoryBase` whichultimately drops the `Arc`. So that's an `Arc` clone and drop just to geta `VMMemoryDefinition`, which is just a pointer and a length, essentially aslice of the linear memory. And, among other places, we call`LocalMemory::vmmemory` to get the GC heap's memory base and bound every time weaccess a GC object from Rust (for example, during collections).Altogether, this removes another 30% of runtime from the testcase inhttps://github.com/bytecodealliance/wasmtime/issues/11141* Construct `VMMemoryDefinition`s in the `RuntimeLinearMemory` implementationInstead of in `LocalMemory` via calling various `RuntimeLinearMemory` methods,as `LocalMemory` has a `dyn RuntimeLinearMemory` object so those calls are allindirect. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs

c81df203 - Fix globals/tables holding their registered types (#11103)

Tue, 24 Jun 2025 14:53:08 +0000

Fix globals/tables holding their registered types (#11103)This commit fixes an issue where host-created tables and globals withconcrete reference types previously did not keep their associated typeregistrations alive for the duration of the table or global itself. Thiscould lead to runtime panics when reflecting on their type andadditionally lead to some type confusion about the global/table itself.As described in #11102 this is not a security issue, just a bug thatneeds fixing.Closes #11102 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs

e012eeda - Remove Stored from wasmtime::Instance (#10909)

Tue, 03 Jun 2025 14:59:25 +0000

Remove Stored from wasmtime::Instance (#10909)* Remove the "export cache" on instancesThis is now a relic of the past now that conversion from the internalto external representation of Wasmtime items is free. This iseffectively dead code that is no longer needed.* Remove `Stored` from `wasmtime::Instance`Powered by all previous commits this is a near-trivial change where an`Instance` is now more-or-less "just" an `InstanceId`. Additionally the`host_state: Box` is no longer needed within `vm::Instance` sothat was removed as well. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs

ef921e81 - Update pinned nightly used in CI (#10893)

Mon, 02 Jun 2025 18:01:10 +0000

Update pinned nightly used in CI (#10893)* Update pinned nightly used in CIResolves some various warnings cropping up from rustc/clippy. This doestrigger what for us is a false positive (I believe) dead code warningwhich I've annotated as `#[allow]` for now (alas this can't be`#[expect]` because it's a nighly-only warning).* Remove dead methods when component-model is disabled List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs

ed20d93d - Store an `InstanceId` in `vm::Instance` (#10872)

Fri, 30 May 2025 21:16:31 +0000

Store an `InstanceId` in `vm::Instance` (#10872)* Store an `InstanceId` in `vm::Instance`This commit is the beginning of an effort to clean up `unsafe`-relatedcode about how we manage instances in the guts of Wasmtime. This doesn'thave any affect on the public API but it's will result eventually inchanges to the internals of types in the public API. This change is alsodone in preparation for simplifying `Stored` and how it works inWasmtime to avoid requiring allocations (aka pushing onto a `StoreData`vector) when converting from Wasmtime's internal representation to theexternal representation of tables, globals, memories, etc.For now all this commit does is add `id: InstanceId` to the`vm::Instance` structure. This led to some refactorings to ensure thatit's correctly listed by centralizing various methods to allocate aninstance into one helper method which manages this configuration.* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs