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

1308d0ac - Fix off-by-one bounds check for atomic operations (#11977)

Tue, 04 Nov 2025 18:34:44 +0000

Fix off-by-one bounds check for atomic operations (#11977)They're allowed to happen if the final address is the memory's length,as opposed to being one-less-than-the-memory's length.Closes #11975 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory.rs

509df0df - Refactor resetting memory on `MemoryImageSlot` drop (#11510)

Mon, 25 Aug 2025 19:15:58 +0000

Refactor resetting memory on `MemoryImageSlot` drop (#11510)* Refactor resetting memory on `MemoryImageSlot` dropThis commit refactors the behavior of dropping a `MemoryImageSlot` to nolonger map anonymous memory into the slot. This behavior was implementedpreviously because if a `MemoryImageSlot` is dropped then the state ofthe slot is unknown and to prevent any sort of data leakage a reset isperformed.This reset operation, however, is fallible in that it calls `mmap`.Calls to `mmap` can fail due to `ENOMEM`, for example, if the processhas reached its VMA limit. This means that if a process is in a near-OOMcondition then failing to allocate a memory image could panic theprocess due to the `unwrap()` in the destructor of `MemoryImageSlot`.The purpose of this commit is to avoid this `unwrap()` and instead movethe reset behavior to a location where an error can be propagated.This commit removes the clear-on-drop behavior of `MemoryImageSlot`slot. This was already disabled everywhere except the pooling allocator.The pooling allocator now maintains an extra bit of state-per-slot whereinstead of storing `Option` it now stores effectivelyone other variant of "unknown". On reuse of an "unknown" slot the memoryis reset back to an anonymous mapping and this is all done in a contextwhere an error can be propagated.Two tests are added in this commit to confirm all of this behavior:* The first test is a new test that passes both before and after this commit which performs a failed allocation of a memory slot. A successful allocation is then made to ensure that the previous image is not present and zero memory is present. This test fails before the commit if the clear-on-drop behavior is removed, and it fails with this commit if the clear-on-reusing-unknown behavior is removed. Effectively this test ensures that the clear-on-unknown-state logic is present.* The second test is a new test that panicked before this commit and passes afterwards. This second test exhausts all VMAs in the current process, or at least most of them, and then tries to allocate some instances with an image. Instance allocation will eventually fail and cause the erroneous path to get executed. This previously unwrapped a `ENOMEM` failure, and now it can be handled gracefully by the embedder.* Skip the new test on QEMU, it fails on CI* Only run test on Linux List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/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.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.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/vm/memory.rs

5c267b56 - Cache the `VMMemoryDefinition` in the DRC collector (#11167)

Tue, 01 Jul 2025 00:11:25 +0000

Cache the `VMMemoryDefinition` in the DRC collector (#11167)Removes about 1/8th of the time spent in the test case inhttps://github.com/bytecodealliance/wasmtime/issues/11141 for me locally.Fixes https://github.com/bytecodealliance/wasmtime/issues/11163 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/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/vm/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.rs

24620d9f - Enable warnings if `pooling-allocator` is disabled (#10142)

Tue, 28 Jan 2025 22:13:04 +0000

Enable warnings if `pooling-allocator` is disabled (#10142)* Enable warnings if `pooling-allocator` is disabledContinuation of work in #10131* Fix windows build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory.rs

cfef9fb1 - Enable warnings if `threads` is disabled (#10136)

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

Enable warnings if `threads` is disabled (#10136)Continuation of work in #10131 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/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.rs

7f9049b9 - Replace `signals-based-traps` with auto-detection (#9941)

Wed, 15 Jan 2025 01:15:14 +0000

Replace `signals-based-traps` with auto-detection (#9941)* Replace `signals-based-traps` with auto-detectionThis commit refactors the platform support of the `wasmtime` crateitself to remove the previously added `signals-based-traps` feature infavor of auto-detecting whether it's there or not. The `build.rs`script for the `wasmtime` crate will now detect the target platform andauto-enable this feature as necessary.The `signals-based-traps` cargo feature is removed and split into twocustom `#[cfg]` directives that the build script sets:* `has_virtual_memory` - this is used to gate mmap implementations for example. This is enabled on `unix || windows` and will be off for `no_std` targets for example. This is split out of "signals-based-traps" to better handle platforms like iOS which have virtual memory but don't execute native code (removing the need for native signals).* `has_native_signals` - gates signal handlers on Unix for example. This is disabled on MIRI but otherwise enabled for `unix || windows`. This is intended to in the future get disabled for iOS by default for example since it's not necessary when using Pulley. This is additionally off-by-default for `no_std` platforms.Two new crate features were added for `no_std` or "custom" platforms toopt-in to the `wasmtime-platform.h` C APIs for implementing virtualmemory and signals. These are used in the `min-platform` embedding example.This commit additionally updates some various documentation here andthere to be more up-to-date.* Update CI configuration* Fix compile warnings* Fix test on miri* Fix more tests on miri* Fix some warnings* Another round of miri/CI attempts/fixesprtest:full List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory.rs

bb68f416 - pulley: Ungate memory64 feature (#9780)

Wed, 11 Dec 2024 15:48:07 +0000

pulley: Ungate memory64 feature (#9780)* pulley: Ungate memory64 featureThis commit is similar to #9779 in that it's removing a proposal fromthe "known list of panicking features" for Pulley to allow more tests torun on Pulley. This then fills out a few miscellaneous instructions toget a full suite of tests passing in Pulley related to memory64 andother instructions.prtest:full* Add notes about spectre speculation List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory.rs

d5ee2a04 - Move MemoryImageSource::map_at to mmap module (#9687)

Fri, 06 Dec 2024 23:51:06 +0000

Move MemoryImageSource::map_at to mmap module (#9687)* Simplify mmap interface slightlyReturn a single `SendSyncPtr` -- the platform-independent context converts tothe various raw pointer types as desired. This simplifies upcoming work where Iwanted to return a `SendSyncPtr`.* Move MemoryImageSource::map_at to mmap moduleThis is part of the work to centralize memory management into the `mmap`module. This commit introduces a few structures which aid in that process, andstarts converting one of the functions (`MemoryImageSource::map_at`) into thismodule.The structures introduced are:* `MemoryBase`: `RuntimeLinearMemory::base_ptr` is now `RuntimeLinearMemory::base`, which returns a `MemoryBase`. This is either a raw pointer or an `MmapOffset` as described below.* `MmapOffset`: A combination of a reference to an mmap and an offset into it. Logically represents a pointer into a mapped section of memory.In future work, we'll move more image-mapping code over to `Mmap` instances. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory.rs

1f812627 - Test Pulley on CI on 32-bit architectures (#9745)

Fri, 06 Dec 2024 20:57:40 +0000

Test Pulley on CI on 32-bit architectures (#9745)This commit extends our CI for i686 and armv7 to test the Pulleybackend, namely the full `*.wast` test suite as well as the `wasmtime`crate itself. Note that many `*.wast` tests are still expected to failat this time.This involved fixing a number of 32-vs-64 bit issues throughout the testsuite in various location in this commit. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory.rs

21477c7c - move most of runtime/vm/cow.rs over to aligned byte counts (#9652)

Fri, 22 Nov 2024 23:30:08 +0000

move most of runtime/vm/cow.rs over to aligned byte counts (#9652)* move most of runtime/vm/cow.rs over to aligned byte countsAs part of attempting to move some of these operations over to Mmap instances,it is nice to have type-level checking for aligned sizes. In upcoming PRs, APIslike `map_at` will be switched to using `Mmap` instances with aligned counts.There are a couple of spots where I have questions -- will flag them in reviewcomments.* address review comments, incl workaround for #9660 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory.rs

34504fed - Move `memory_init_cow` option to `Tunables` (#9632)

Wed, 20 Nov 2024 17:56:51 +0000

Move `memory_init_cow` option to `Tunables` (#9632)This commit moves the configuration option from `Config` to `Tunables`to ensure that the memory allocation backend has access to it and thenit's used to specifically avoid choosing a malloc-based memory becauseCoW isn't compatible with malloc. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory.rs