Changes in shared_memory.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/vm/memory/shared_memory.rs

b860c2c6 - Adjust behavior of 4gb memories with custom page sizes (#12884)

Mon, 30 Mar 2026 14:52:21 +0000

Adjust behavior of 4gb memories with custom page sizes (#12884)* Adjust behavior of 4gb memories with custom page sizesThis commit adjust what happens when a linear memory grows up to 4gblarge when custom page sizes are used. This is an open question in theupstream proposal at WebAssembly/custom-page-sizes#45 but without anyspecial handling a return value of -1 is ambiguous if it succeeded orfailed. For now eagerly trap memory operations reaching these conditionswhile the upstream specification question is resolved.* Fix CI* Debug CI failureprtest:full* Fix 32-bit platforms List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory/shared_memory.rs

0a55f804 - "Downgrade" threads support to tier 2, disable fuzzing (#12036)

Mon, 24 Nov 2025 17:09:20 +0000

"Downgrade" threads support to tier 2, disable fuzzing (#12036)* "Downgrade" threads support to tier 2, disable fuzzingThis commit is borne out of a fuzz bug that was opened recently. Thefuzz bug specifically has to do with fallout from #12022, specifically`SharedMemory` being used to allocated instead of `Memory`. In thissituation the resource limiter is no longer consulted meaning thatshared memories bypass this and aren't caught by OOM checks. This iscurrently by design because `SharedMemory` instances don't know whichresource limiter to hook into per-store.More generally though the implementation of wasm threads, while workablein Wasmtime, has a number of known relatively large deficiencies. Thesewere not resolved prior to ungating the wasm proposal (that's on me) butnevertheless the quality of implementation is not quite up to "tier 1par" with the rest of what Wasmtime offers. Given this the threadsproposal is now downgraded to tier 2. To help minimize the impact ofthis the wasm proposal is left enabled-by-default, but creation of a`SharedMemory` in the Rust API requires opting-in via a new`Config::shared_memory` method.This commit shuffles around some documentation of wasm proposals tosplit it into tier 1/2/3 instead of on/off-by-default and then adds acolumn for whether the proposal is on-by-default.* clangformat* Fix tests* Add tests for failed creationFix an issue where defined shared memories weren't gated* Sync disabled threads stub* Fix another testprtest:full* Fix fuzzing tests* Fix dwarf tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory/shared_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/vm/memory/shared_memory.rs

f881ab24 - Make memory growth an async function (#11460)

Tue, 19 Aug 2025 21:06:31 +0000

Make memory growth an async function (#11460)* Make memory growth an `async` functionThis is an analog of #11442 but for memories. This had a little moreimpact due to memories being hooked into GC operations. Furtherrefactoring of GC operations to make them safer/more-async is deferredto a future PR and for now it's "no worse than before". This is anotherstep towards #11430 and enables removing a longstanding `unsafe` blockin `runtime/memory.rs` which previously could not be removed.One semantic change from this is that growth of a shared memory nolonger uses an async limiter. This is done to keep growth of a sharedmemory consistent with creation of a shared memory where no limits areapplied. This is due to the cross-store nature of shared memories whichmeans that we can't tie growth to any one particular store. Thisadditionally fixes an issue where an rwlock write guard was otherwiseheld across a `.await` point which creates a non-`Send` future, closinga possible soundness hole in Wasmtime.* Fix threads-disabled build* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory/shared_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/vm/memory/shared_memory.rs

16f069c5 - Make a couple `vm::Memory` methods take `&self` instead of `&mut self` (#10543)

Mon, 07 Apr 2025 21:40:02 +0000

Make a couple `vm::Memory` methods take `&self` instead of `&mut self` (#10543)The `&mut self` was not necessary and also did not provide any help with usingthe resulting `VMMemoryDefinition`s and their raw pointers, so just make thesemethods take `&self`. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory/shared_memory.rs

a7d76ecb - Enable warnings if `component-model` is disabled (#10141)

Tue, 28 Jan 2025 20:17:08 +0000

Enable warnings if `component-model` is disabled (#10141)Continuation of work in #10131 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory/shared_memory.rs

b86b9682 - Provenance preparation for Pulley (#10043)

Thu, 23 Jan 2025 20:55:28 +0000

Provenance preparation for Pulley (#10043)* Provenance preparation for PulleyThis commit is an internal refactoring of Wasmtime's runtime to prepareto execute Pulley in MIRI. Currently today this is not possible becausePulley does not properly respect either strict or permissive provenancemodels. The goal of this refactoring is to enable fixing this in afuture commit that doesn't touch everything in the codebase. Insteadeverything is touched here in this commit.The basic problem with Pulley is that it is incompatible with the strictprovenance model of Rust which means that we'll be using "exposedprovenance" APIs to satisfy Rust's soundness requirements. In this modelwe must explicitly call `ptr.expose_provenance()` on any pointerswhich are exposed to compiled code. Arguably we should also be alreadydoing this for natively-compiled code but I am not certain about howstrictly this is required.Currently in Wasmtime today we call `ptr.expose_provenance()` nowhere.It also turns out, though, that we share quite a few pointers in quite afew places with compiled code. This creates a bit of a problem! Thesolution settled on in this commit looks like:* A new marker trait, `VmSafe`, is introduced. This trait is used to represent "safe to share with compiled code" types and enumerates some properties such as defined ABIs, primitives wrappers match primitive ABIs, and notably "does not contain a pointer".* A new type, `VmPtr`, is added to represent pointers shared with compiled code. Internally for now this is just `SendSyncPtr` but in the future it will be `usize`. By using `SendSyncPtr` it shouldn't actually really change anything today other than requiring a lot of refactoring to get the types to line up.* The core `vmctx_plus_offset*` methods are updated to require `T: VmSafe`. Previously they allowed any `T` which is relatively dangerous to store any possible Rust type in Cranelift-accessible areas.These three fundamental changes were introduced in this commit. Allfurther changes were refactoring necessary to get everything workingafter these changes. For example many types in `vmcontext.rs`, such as`VMFuncRef`, have changed to using `VmPtr` instead of `NonNull` or`*mut T`. This is a pretty expansive change which resulted in touching alot of places.One premise of `VmPtr` is that it's non-null. This was anadditional refactoring that updated a lot of places where previously`*mut T` was used and now either `VmPtr` or `NonNull` is used.In the end the intention is that `VmPtr` is used whenever pointersare store in memory that can be accessed from Cranelift. When operatinginside of the runtime `NonNull` or `SendSyncPtr` is preferredinstead.As a final note, no provenance changes have actually happened yet. Forexample this doesn't fix Pulley in MIRI. What it does enable, though, isthat the future commit to fix Pulley in MIRI will be much smaller withthis having already landed.* Run the full test suite in PR CIprtest:full* Minor CI issues* Fix no_std build* Fix miri build* Don't use `VmPtr` in FFI function signaturesUse `NonNull` or `*mut u8` as appropriate for function signaturesinstead. It shouldn't be required to use `VmPtr` during the handoff tocompiled code as we've already annotated the pointer going out.* Fix rebase conflict* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory/shared_memory.rs

d3132c9d - Add a `signals-based-traps` Cargo compile-time feature (#9614)

Tue, 19 Nov 2024 19:21:36 +0000

Add a `signals-based-traps` Cargo compile-time feature (#9614)* Gate signal handlers behind a new Cargo featureThis commit adds a new on-by-default Cargo feature to the `wasmtime`crate named `signals-based-traps`. This is modeled after the`Config::signals_based_traps` configuration at runtime and can be usedto statically disable the use of signal handlers in Wasmtime. Thisnotably reduces the number of platform dependencies that Wasmtime hasand provides a mode of avoiding relying on signals altogether.This introduces a new `MallocMemory` which is a linear memory backed bythe system allocator. This new type of memory is enabled when virtualmemory guards are disabled and signals-based-traps are disabled. Thismeans that this new type of memory will be candidate for fuzzing forexample.prtest:full* Fix rebase conflict* Refactor `MmapVec` documentation and representation* Remove no-longer-needed `Arc`* Document it may be backed by `Vec` List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory/shared_memory.rs