Changes in allocator.rs

517c0287 - Use traps when checking initial table/memory bounds (#12929)

Wed, 01 Apr 2026 14:51:19 +0000

Use traps when checking initial table/memory bounds (#12929)Instead of using a custom error string this enables fuzzing to, forexample, see that a `Trap` was returned and consider the fuzz test casea normal failure. These code paths are only executed when `bulk_memory`is disabled which is pretty rare, and also explains why it's come up infuzzing only just now after #12883. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator.rs

9c3ed199 - Fix table64 initialization when bulk memory is disabled (#12894)

Mon, 30 Mar 2026 20:36:56 +0000

Fix table64 initialization when bulk memory is disabled (#12894)* Fix table64 initialization when bulk memory is disabledThis commit fixes a panic in the host during instantiation when the`bulk_memory` wasm feature is disabled. In this mode the initializationof tables/memories is slightly different and a refactoring for 64-bitsupport wasn't applied to this code path, meaning that it resulted in apanic instead of properly handling 64-bit tables.* Fix clippy List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator.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/vm/instance/allocator.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/vm/instance/allocator.rs

9c44a9b4 - Use `TryPrimaryMap` in `Instance` (#12848)

Thu, 26 Mar 2026 18:26:52 +0000

Use `TryPrimaryMap` in `Instance` (#12848) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator.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/instance/allocator.rs

58ce6b8b - Remove unnecessary `memory_tys` param from `vm::Instance::new` (#12414)

Fri, 23 Jan 2026 20:40:41 +0000

Remove unnecessary `memory_tys` param from `vm::Instance::new` (#12414)We already have this information in the `InstanceAllocationRequest`, and byavoiding a parameter we can never accidentally pass the wrong memory types. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator.rs

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

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

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

79419198 - Don't unwrap results of const-eval (#11557)

Thu, 28 Aug 2025 19:50:56 +0000

Don't unwrap results of const-eval (#11557)While all const expressions executed at runtime are valid they can stillfail due to GC OOM or failure to allocate more GC memory. As a resultall `unwrap()` on `eval(...)` is removed in favor of propagatingupwards the result.Closes #11469 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator.rs

becdee57 - Add PoolingAllocatorMetrics (#11490)

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

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

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

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

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

d1397130 - Make const-expr evaluation `async` (#11468)

Wed, 20 Aug 2025 17:27:05 +0000

Make const-expr evaluation `async` (#11468)* Make const-expr evaluation `async`This commit is extracted from #11430 to accurately reflect howconst-expr evaluation is an async operation due to GC pauses that mayhappen. The changes in this commit are:* Const-expr evaluation is, at its core, now an `async` function.* To leverage this new `async`-ness all internal operations are switched from `*_maybe_async` to `*_async` meaning all the `*_maybe_async` methods can be removed.* Some libcalls using `*_maybe_async` are switch to using `*_async` plus the `block_on!` utility to help jettison more `*_maybe_async` methods.* Instance initialization is now an `async` function. This is temporarily handled with `block_on` during instance initialization to avoid propagating the `async`-ness further upwards. This `block_on` will get deleted in future refactorings.* Const-expr evaluation has been refactored slightly to enable having a fast path in global initialization which skips an `await` point entirely, achieving performance-parity in benchmarks prior to this commit.This ended up fixing a niche issue with GC where if a wasm execution wassuspended during `table.init`, for example, during a const-exprevaluation triggering a GC then if the wasm execution was cancelled itwould panic the host. This panic was because the GC operation returned`Result` but it was `unwrap`'d as part of the const-expr evaluationwhich can fail not only to invalid-ness but also due to "computation iscancelled" traps.* Fix configured build* Undo rebase mistake List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator.rs

94a8bb8c - Use another RAII guard for instance allocation (#11466)

Tue, 19 Aug 2025 21:30:41 +0000

Use another RAII guard for instance allocation (#11466)Forgotten from #11459 and extracted from #11430, uses an RAII guardinstead of a closure to handle errors. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator.rs

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

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

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

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

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

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

c6dddeaf - Minimize lazy allocation of the GC store (#11411)

Mon, 11 Aug 2025 20:47:20 +0000

Minimize lazy allocation of the GC store (#11411)* Minimize lazy allocation of the GC storeThis commit is an effort to minimize the number of entrypoints whichmight lazily allocate a GC store. The is currently done through`StoreOpaque::gc_store_mut` but this method is very commonly usedmeaning that there are many many places to audit for lazily allocating aGC store. The reason that this needs an audit is that lazy allocationis an async operation right now that must be on a fiber and is somethingI'm looking to fix as part of #11262.This commit performs a few refactorings to achieve this:* `gc_store_mut` is renamed to `ensure_gc_store`. This is intended to be an `async` function in the future and clearly demarcates where lazy allocation of a GC store is occurring.* `require_gc_store{,_mut}` is now added which is a pure accessor of the GC store with no lazy allocation. Most locations previously using `gc_store_mut` are updated to use this instead.Documentation is added to store methods to clearly indicate which onesare allocating and which ones should only be called in a context whereallocation should already have happened.* Fix configured build* Relax GC store restrictions in more places* Review comments on documentation* Move `ensure_gc_store` calls during instantiationInstead update `needs_gc_heap` with the tables that are added to amodule and rely on instantiation to create the GC heap.* Shuffle around some code* Fix CI and review comments* Add in a few more i31 cases for externref List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator.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/vm/instance/allocator.rs

b052dee0 - Deny `unsafe_op_in_unsafe_fn` in `wasmtime::vm::instance` (#11267)

Thu, 17 Jul 2025 19:44:19 +0000

Deny `unsafe_op_in_unsafe_fn` in `wasmtime::vm::instance` (#11267)Turn the lint on and add some safety comments where appropriate.cc #11180 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator.rs

f021346e - More table safety improvements (#11255)

Thu, 17 Jul 2025 17:15:13 +0000

More table safety improvements (#11255)* More table safety improvementsThis is some more progress on #11179 aimed at improving the safety ofmanagement of tables internally within Wasmtime:* `Instance::table_index` is removed as it can be replaced with data stored directly in the `VMTableImport` now.* `Instance::get_table` now returns `&mut Table`* `Instance::get_defined_table_with_lazy_init` now returns `&mut Table`* `Instance::with_defined_table_index_and_instance` now directly returns `DefinedTableIndex` plus `Pin<&mut Instance>`, codifying the ability to "laterally move" between instances.* `Instance::table_init_segment` was refactored to "take" the tables during initialization and replace them afterwards, resolving the split borrow issue and removing an `unsafe` block in the function.cc #11179* Improve safety of `Table::copy`This commit fixes an issue in the previous commit with respect to Miriand Stacked Borrows. This does so by improving the safety of the`Table::copy`-related functions to all work mostly on safe code ratherthan unsafe references. Some minor amount of unsafety is still presentbut it is now clearly documented and easier to verify.* Fix tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator.rs