Stream: git-wasmtime

Topic: wasmtime / issue #14989 Proposal to rework `MemoryCreator...

Wasmtime GitHub notifications bot (Oct 25 2026 at 17:22):

V0ldek opened issue #14989:

Building on #14885, I'd like to tackle the other half of the linear memory traits. This is already a FIXME in the memory code:

https://github.com/bytecodealliance/wasmtime/blob/ffff2e2db24a291f02429f123aba1631fa8eea67/crates/wasmtime/src/runtime/vm/memory.rs#L73-L74

Since it involves a breaking public API change I thought I'd first go through an issue before I go into slashing the codebase.

Feature

The change would remove RuntimeMemoryCreator and MemoryCreatorProxy. The DefaultMemoryCreator struct would be implemented wholly in terms of the public MemoryCreator trait.

This requires a breaking change to the MemoryCreator. First, the DefaultMemoryCreator receives reservation_for_growth, which is currently not present on the public trait's new_memory. Second, more minor, the current trait requires to return a Result<_, String> instead of the standard wasmtime error type, so fidelity would be lost as the DefaultMemoryCreator would convert all strongly-typed errors to string.

Benefit

Simplifies the code base, fixes an outstanding FIXME, avoids running into issues similar to #10740 because of a mismatch of how the user can implement the memory backend from the outside and internal-only shortcuts.

Implementation

My proposal would be to change the public API so that new_memory task a single parameter, MemoryRequest. That way things can be added as functions on the type without breaking current implementations. Public accessors on the request would return all things the creator needs to serve the request:

impl<'a> MemoryRequest<'a> {
  pub fn ty(&self) -> MemoryType;
  pub fn minimum(&self) -> usize;
  pub fn maximum(&self) -> Option<usize>;
  pub fn reserved_size_in_bytes(&self) -> Option<usize>;
  pub fn guard_size_in_bytes(&self) -> usize;
}

The return type turns into the standard wasmtime Error. This is not really an issue, a user of wasmtime already has to cope with the wasmtime Error anywhere, I don't think there's any advantage to allowing Result<_, String> as it currently is.

Internally, RuntimeMemoryCreator is gone, as is MemoryCreatorProxy. Config holds an Arc<dyn MemoryCreator> instead. The implementation that creates memory in vm::Memory will construct a MemoryRequest and route it to the creator.

Not all things are exposed publicly, I don't necessarily want to increase the public API surface here. The DefaultMemoryCreator needs MemoryTunables for some of the config as well as ty: &wasmtime_environ::Memory. These are not public types, so I'd keep them on MemoryRequest exposed as pub(crate), but not to the outside.

Alternatives

There's a few things one could consider changing:

1. The documentation now doesn't mention that, but the custom creator is also used for GC heaps. An implementation might want to serve these differently, because their purpose and access patterns are different, but currently there's no way to distinguish that from the public parameters. A simple pub fn kind(&self) returning a non-exhausting MemoryKind enum with LinearMemory and GcHeap fixes this.
2. The other parameters are passed via tunables and not exposed. For example, MmapMemory uses reservation_for_growth and guard_before_linear_memory, plus signals_based_traps and memory_init_cow to decide whether to use Mmap or Malloc-backed memory.

I also have one open question: reserved_size_in_bytes is an Option<usize>, but the engine always passes Some, with Some(0) meaning "no reservation". Is there any reason for this? What would be the semantic difference between Some(0) and None? Can we just make it a usize?

Wasmtime GitHub notifications bot (Oct 26 2026 at 15:16):

alexcrichton added the wasmtime:api label to Issue #14989.

Wasmtime GitHub notifications bot (Oct 26 2026 at 15:18):

alexcrichton commented on issue #14989:

This all sounds reasonable to me, thanks for working on this!

For MemoryRequest<'a> one downside of that approach is the loss of compiler warnings if you forget to take into account some parameter/field. Not a deal-breaker per-se and it's nice to not break the API when new functionality is added, but in this situation I think it's probably more important to expose all the parameters since if we add one we probably do want to break all downstream consumers as they'll need to update to account for it.

For reserved_size_in_bytes that might just be a historical artifact being Option-vs-not, and if it's always Some feel free to unwrap it.

Wasmtime GitHub notifications bot (Oct 27 2026 at 15:24):

V0ldek commented on issue #14989:

The problem with passing arguments directly is that then we cannot hide internal parameters. The alternative would be to expose MemoryTunables and wasmtime_environ::Memory as parameters of the new_memory function, but neither of those types are part of the public API of wasmtime currently.

Wasmtime GitHub notifications bot (Oct 27 2026 at 15:26):

V0ldek edited a comment on issue #14989:

The problem with passing arguments directly is that then we cannot hide internal parameters. The alternative would be to expose MemoryTunables and wasmtime_environ::Memory as parameters of the new_memory function, but neither of those types are part of the public API of wasmtime currently.

I guess the question here is whether we want to keep hiding things, or do we want full parity (i.e. an outside user could build exactly the wasmtime::DefaultMemoryCreator). We could expose just the parameters that are actively used (reservation_for_growth, guard_before_linear_memory, signals_based_traps, memory_init_cow).

Wasmtime GitHub notifications bot (Oct 28 2026 at 00:50):

alexcrichton commented on issue #14989:

Ah sorry I missed that part of the OP here, and good point! In tha tcase seems reasonable to me to have a MemoryRequest<'_> and we can tweak the documentation over time of what's required vs what isn't

Last updated: Oct 31 2026 at 23:03 UTC