History log of /wasmtime-44.0.1/crates/wasmtime/src/runtime/trampoline/memory.rs (Results 1 – 25 of 43)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7
# 9bc302ad 30-Mar-2026 Alex Crichton <[email protected]>

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

This is a follow-on to #12849 to try to simplify some of the resulting
signatures a bit. Notably the `Result<..., OutOfMemory>`

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

This is a follow-on to #12849 to try to simplify some of the resulting
signatures a bit. Notably the `Result<..., OutOfMemory>` is now packaged
up directly into the output future, so the functions still retain a sort
of "async trait" feel even though they're still incompatible with
`#[async_trait]` (and can't be defined with that anyway).

show more ...


# d2dee5dd 27-Mar-2026 Nick Fitzgerald <[email protected]>

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

* Use `try_new` for `Box<dyn RuntimeLinearMemory>` in `DefaultMemoryCreator`

* Use `TryPrim

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

* Use `try_new` for `Box<dyn RuntimeLinearMemory>` in `DefaultMemoryCreator`

* Use `TryPrimaryMap` for `host_globals` in `Store`

* Add `Func::try_wrap` and use `try_new` for `Box<HostFunc>`

Add `Func::try_wrap` as a fallible version of `Func::wrap` that returns an error
on out-of-memory instead of panicking. `Func::wrap` now delegates to `try_wrap`.

Also use `try_new::<Box<_>>` instead of `Box::new` for `HostFunc`.

* Use `bumpalo`'s `try_alloc` for `FuncRefs`

* Use `try_new` for `Arc<Module>` in "trampoline" code

* Test that we handle OOM in `{Func,Memory,Table,Global}::new` and when calling an instance's exported function

* cargo fmt

show more ...


# 82ebbd5d 26-Mar-2026 Nick Fitzgerald <[email protected]>

Use explicit boxing for InstanceAllocator async methods (#12849)

Change `allocate_memory` and `allocate_table` in the `InstanceAllocator` trait
from `async fn`s to regular `fn`s that return `Result<

Use explicit boxing for InstanceAllocator async methods (#12849)

Change `allocate_memory` and `allocate_table` in the `InstanceAllocator` trait
from `async fn`s to regular `fn`s that return `Result<Pin<Box<dyn Future<...>>>,
OutOfMemory>`.

This avoids the implicit `Box::new` allocation that `#[async_trait]` generates
when calling these methods through `dyn InstanceAllocator`, which would panic on
OOM instead of returning an error. Now the boxing is done explicitly via
`try_new::<Box<_>>` which returns `Err(OutOfMemory)` on allocation failure.

show more ...


Revision tags: v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6
# 9c17fed6 18-Feb-2026 Nick Fitzgerald <[email protected]>

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


# 1f16b28f 12-Feb-2026 Nick Fitzgerald <[email protected]>

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

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

show more ...


Revision tags: v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3
# 17899c88 23-Jan-2026 Nick Fitzgerald <[email protected]>

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

* Share empty `ModuleRuntimeInfo`s across all stores in an engine

This avoids an `Arc`- and `Box`-allocation during `Store`

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

* Share empty `ModuleRuntimeInfo`s across all stores in an engine

This 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

show more ...


Revision tags: v41.0.0, v36.0.4, v39.0.2, v40.0.2
# ff33e949 09-Jan-2026 Nick Fitzgerald <[email protected]>

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

We are trying to move to `format_err!` instead.


Revision tags: v40.0.1
# 96e19700 07-Jan-2026 Nick Fitzgerald <[email protected]>

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 `wasmtim

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, redirects
our top-level `wasmtime::{Error, Result}` re-exports to re-export
`wasmtime::error::{Error, Result}`, and updates various use sites that were
directly using `anyhow` to use the new `wasmtime` versions.

This process also required updating the component macro and wit-bindgen macro to
use 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

show more ...


Revision tags: v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0
# 5245e1f8 12-Sep-2025 Nick Fitzgerald <[email protected]>

Remove `AllCallFunc` (#11694)

* Remove `AllCallFunc`

And add `FuncKeyKind` and `FuncKeyNamespace` types.

Split out from https://github.com/bytecodealliance/wasmtime/pull/11630

* fix warning and d

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

show more ...


Revision tags: v36.0.2, v36.0.1
# 155ea7fc 21-Aug-2025 Alex Crichton <[email protected]>

Remove unsoundness of widening store borrows (#11481)

* Remove unsoundness of widening store borrows

This commit removes preexisting unsoundness in Wasmtime where a
`&mut StoreOpaque` borrow was "

Remove unsoundness of widening store borrows (#11481)

* Remove unsoundness of widening store borrows

This commit removes preexisting unsoundness in Wasmtime where a
`&mut StoreOpaque` borrow was "widened" into encompassing the limiter on
the `T` in `StoreInner<T>`, for example, by using the self-pointer
located 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

show more ...


# e1f50aad 21-Aug-2025 Alex Crichton <[email protected]>

Make table/memory creation async functions (#11470)

* Make core instance allocation an `async` function

This commit is a step in preparation for #11430, notably core instance
allocation, or `Store

Make table/memory creation async functions (#11470)

* Make core instance allocation an `async` function

This commit is a step in preparation for #11430, notably core instance
allocation, or `StoreOpaque::allocate_instance` is now an `async fn`.
This function does not actually use the `async`-ness just yet so it's a
noop from that point of view, but this propagates outwards to enough
locations that I wanted to split this off to make future changes more
digestable.

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 as
appropriate as well.

For reference this commit was benchmarked with our `instantiation.rs`
benchmark in the pooling allocator and shows no changes relative to the
original baseline from before-`async`-PRs.

* Make table/memory creation `async` functions

This commit is a large-ish refactor which is made possible by the many
previous refactorings to internals w.r.t. async-in-Wasmtime. The end
goal of this change is that table and memory allocation are both `async`
functions. Achieving this, however, required some refactoring to enable
it 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 but
everything 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

show more ...


Revision tags: v36.0.0
# f8177c20 19-Aug-2025 Alex Crichton <[email protected]>

Refactor `InstanceAllocator` trait impl split (#11457)

Prior to this commit Wasmtime had an `InstanceAllocatorImpl` trait with
a number of required methods as well as an `InstanceAllocator` trait
wi

Refactor `InstanceAllocator` trait impl split (#11457)

Prior to this commit Wasmtime had an `InstanceAllocatorImpl` trait with
a number of required methods as well as an `InstanceAllocator` trait
with a number of provided impls. The `InstanceAllocator` trait is
implemented for everything implementing `InstanceAllocatorImpl` to force
users 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` functions
as a future needs to be heap-allocated.

The goal of this commit is to make this future `async`-ification a bit
more optimal. Notably the `InstanceAllocator` trait is removed and
replaced 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. A
consequence of this is that the inherent methods are also forced to do
virtual dispatch unlike before where they would internally use
monomorphization to have static dispatch. Given the complexity of
instance 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 the
cost of `#[async_trait]`. Only allocation of a single table/memory will
require an allocation of a future which in profiling helps reduce the
cost of instantiation slightly.

Note that `#[async_trait]` is not currently used, this commit is just
preparation for its eventual use.

show more ...


# 0f457fad 25-Jul-2025 Alex Crichton <[email protected]>

Raise `unsafe_op_in_unsafe_fn` further in Wasmtime (#11322)

* Raise `unsafe_op_in_unsafe_fn` further in Wasmtime

Now it's at `wasmtime::runtime`, not just `wasmtime::runtime::vm`.

* Review comments


# 88079b4f 24-Jul-2025 Alex Crichton <[email protected]>

Make table/memory allocation functions safe (#11320)

These were previously marked as `unsafe` trait methods with a
requirement that the memory/table shape must be validated ahead of time.
Neither th

Make table/memory allocation functions safe (#11320)

These were previously marked as `unsafe` trait methods with a
requirement that the memory/table shape must be validated ahead of time.
Neither the ondemand nor pooling allocator actually has an unsafe
contract to uphold with respect to this and both may assert/reject
non-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 the
correctness of `imports` is required for the functions to be safe.

show more ...


Revision tags: v35.0.0, v24.0.4, v33.0.2, v34.0.2
# 046a51ca 27-Jun-2025 Nick Fitzgerald <[email protected]>

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 RuntimeLinearM

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` involved
getting a `MemoryBase` which is potentially an `MmapOffset` which itself
contains an `Arc<Mmap>`, and we would then call `base.as_non_null()` to turn
this into a raw pointer, and then we would drop the `MemoryBase` which
ultimately drops the `Arc<Mmap>`. So that's an `Arc` clone and drop just to get
a `VMMemoryDefinition`, which is just a pointer and a length, essentially a
slice of the linear memory. And, among other places, we call
`LocalMemory::vmmemory` to get the GC heap's memory base and bound every time we
access a GC object from Rust (for example, during collections).

Altogether, this removes another 30% of runtime from the testcase in
https://github.com/bytecodealliance/wasmtime/issues/11141

* Construct `VMMemoryDefinition`s in the `RuntimeLinearMemory` implementation

Instead of in `LocalMemory` via calling various `RuntimeLinearMemory` methods,
as `LocalMemory` has a `dyn RuntimeLinearMemory` object so those calls are all
indirect.

show more ...


Revision tags: v34.0.1, v33.0.1, v24.0.3, v32.0.1
# c81df203 24-Jun-2025 Alex Crichton <[email protected]>

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

This commit fixes an issue where host-created tables and globals with
concrete reference types previously did not keep their associated typ

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

This commit fixes an issue where host-created tables and globals with
concrete reference types previously did not keep their associated type
registrations alive for the duration of the table or global itself. This
could lead to runtime panics when reflecting on their type and
additionally lead to some type confusion about the global/table itself.
As described in #11102 this is not a security issue, just a bug that
needs fixing.

Closes #11102

show more ...


Revision tags: v34.0.0
# e012eeda 03-Jun-2025 Alex Crichton <[email protected]>

Remove Stored from wasmtime::Instance (#10909)

* Remove the "export cache" on instances

This is now a relic of the past now that conversion from the internal
to external representation of Wasmtime

Remove Stored from wasmtime::Instance (#10909)

* Remove the "export cache" on instances

This is now a relic of the past now that conversion from the internal
to external representation of Wasmtime items is free. This is
effectively 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<dyn Any>` is no longer needed within `vm::Instance` so
that was removed as well.

show more ...


# ef921e81 02-Jun-2025 Alex Crichton <[email protected]>

Update pinned nightly used in CI (#10893)

* Update pinned nightly used in CI

Resolves some various warnings cropping up from rustc/clippy. This does
trigger what for us is a false positive (I belie

Update pinned nightly used in CI (#10893)

* Update pinned nightly used in CI

Resolves some various warnings cropping up from rustc/clippy. This does
trigger what for us is a false positive (I believe) dead code warning
which 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

show more ...


# ed20d93d 30-May-2025 Alex Crichton <[email protected]>

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`-related
code about how we manage instances

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`-related
code about how we manage instances in the guts of Wasmtime. This doesn't
have any affect on the public API but it's will result eventually in
changes to the internals of types in the public API. This change is also
done in preparation for simplifying `Stored<T>` and how it works in
Wasmtime to avoid requiring allocations (aka pushing onto a `StoreData`
vector) when converting from Wasmtime's internal representation to the
external 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 that
it's correctly listed by centralizing various methods to allocate an
instance into one helper method which manages this configuration.

* Review comments

show more ...


Revision tags: v33.0.0
# 90ac295e 19-May-2025 Alex Crichton <[email protected]>

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...


Revision tags: v32.0.0
# c22b3cb9 11-Apr-2025 Nick Fitzgerald <[email protected]>

Reuse Wasm linear memories code for GC heaps (#10503)

* Reuse code for Wasm linear memories for GC heaps

Instead of bespoke code paths and structures for Wasm GC, this commit makes it
so that we no

Reuse Wasm linear memories code for GC heaps (#10503)

* Reuse code for Wasm linear memories for GC heaps

Instead of bespoke code paths and structures for Wasm GC, this commit makes it
so that we now reuse VM structures like `VMMemoryDefinition` and bounds-checking
logic. Notably, we also reuse all the associated bounds-checking optimizations
and, when possible, virtual-memory techniques to completely elide them.

Furthermore, this commit adds support for growing GC heaps, reusing the
machinery for growing memories, and makes it so that GC heaps always start out
empty. This allows us to properly delay allocating the GC heap's storage until a
GC object is actually allocated.

Fixes #9350

* fix c api compilation

* use assert_contains

* remove no-longer-necessary extra memory config from limiter tests

* Helper for retry-after-maybe-async-gc in libcalls

* Clean up some comments

* fix wasmtime-fuzzing and no-gc compilation

* fix examples

* fix no-gc+compiler build

* fix build without pooling allocator

* fix +cranelift +gc-drc -gc-null builds

* fix table hash key stability test

* fix oracle usage of `ExternRef::new`

* fix +gc -gc-null -gc-drc build

* fix wasmtime-fuzzing

* make `StorePtr` wrap a `NonNull`

* Fix some doc tests

* Remove some unnecessary retry helpers now that `FooRef::new` will auto-gc

* fix things after rebase

* Reorganize collection/growth methods for GC heap

* rename BoundsCheck variants

* fix cfg'ing of gc only code

* Fix doc tests

* fix one more gc cfg

* disable GC heap OOM test on non-64-bit targets

show more ...


# eafe7439 25-Mar-2025 Nick Fitzgerald <[email protected]>

Do not reorder/pack struct fields (#10463)

* Do not reorder/pack struct fields

We were not considering that when a type T is a subtype of type U, that all of
the fields that T and U share must be a

Do not reorder/pack struct fields (#10463)

* Do not reorder/pack struct fields

We were not considering that when a type T is a subtype of type U, that all of
the fields that T and U share must be at the same offsets. Our
reordering/packing algorithm did not consider this. So we stop reordering struct
fields for now.

This also means that we cannot guarantee that all GC refs in an object are
contiguously packed anymore. Instead, we maintain a map keyed by
`VMSharedTypeIndex`, whose value is all the offsets of outgoing GC
references for instances of that type. Tracing looks up the current object's
type in this map, and then extracts each of the GC edges.

This new tracing scheme means that we no longer need to store the number of
outgoing edges in the GC object header, and can put the object size in there
again, reducing the DRC header from 24 to 16 bytes.

Fixes #10459
Fixes #10464

* Correctly handle `Layout` errors in `libcalls::gc_alloc_raw`

show more ...


Revision tags: v31.0.0, v30.0.2, v30.0.1, v30.0.0
# a727985c 30-Jan-2025 Alex Crichton <[email protected]>

Enable warnings if `gc` is disabled (#10149)

* Enable warnings if `gc` is disabled

Continuation of work in #10131. This additionally handles turning off
`gc-null` and `gc-drc` and the various combi

Enable warnings if `gc` is disabled (#10149)

* Enable warnings if `gc` is disabled

Continuation of work in #10131. This additionally handles turning off
`gc-null` and `gc-drc` and the various combinations within.

* Fix some more warnings

* Fix a feature combo build

show more ...


Revision tags: v29.0.1, v29.0.0, v28.0.1, v28.0.0
# d5ee2a04 06-Dec-2024 Rain <[email protected]>

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

* Simplify mmap interface slightly

Return a single `SendSyncPtr` -- the platform-independent context converts to
the various raw pointer types

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

* Simplify mmap interface slightly

Return a single `SendSyncPtr` -- the platform-independent context converts to
the various raw pointer types as desired. This simplifies upcoming work where I
wanted to return a `SendSyncPtr`.

* Move MemoryImageSource::map_at to mmap module

This is part of the work to centralize memory management into the `mmap`
module. This commit introduces a few structures which aid in that process, and
starts converting one of the functions (`MemoryImageSource::map_at`) into this
module.

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.

show more ...


Revision tags: v27.0.0
# 81d7de0a 07-Nov-2024 Alex Crichton <[email protected]>

Remove the `MemoryStyle` enum (#9583)

* Remove the `MemoryStyle` enum

There are no more major users left, only a few minor pieces here and
there. This should complete the refactoring to delete the

Remove the `MemoryStyle` enum (#9583)

* Remove the `MemoryStyle` enum

There are no more major users left, only a few minor pieces here and
there. This should complete the refactoring to delete the "static" and
"dynamic" terminology from Wasmtime and all we're left with are linear
memories with a few knobs in `Tunables`.

* Fix test compile

show more ...


12