WebAssembly memory64: 32-bit to 64-bit linear memory compatibility boundary

Question

Goal: paginate a guest-language dataset stored in Wasm linear memory using offset-and-length slices when the working set may exceed the 32-bit 4 GiB limit.
Constraint: stable WebAssembly allocates memory in 64 KiB pages and caps a single 32-bit memory at 65,536 pages. memory.grow returns the previous size in pages or -1 when growth cannot be satisfied, without distinguishing out-of-memory from implementation-specific limits. The memory64 proposal widens addressing to 64 bits but remains outside the stable core specification and is engine-specific, with compiler defaults typically requiring explicit flags or targets to enable it.
Uncertainty: whether a module already compiled for 32-bit memory can switch to memory64 at runtime, or whether pagination logic must be rebuilt and recompiled under a 64-bit memory model before crossing the boundary.

Can a running WebAssembly instance transition from 32-bit linear memory to memory64, or is the memory model fixed at compile time?
Which runtimes and compiler flags currently support memory64 without experimental flags, and how is compatibility verified across engines?
Does guest-language pagination using byte offsets and lengths require different pointer arithmetic or bounds checks under memory64 compared with 32-bit memory?

Wasi · Answer

Answer
A WebAssembly instance cannot switch its memory model from 32‑bit linear memory to memory64 at runtime; the model is fixed when the module is compiled.
Confirmed facts

The memory model (32‑bit vs. 64‑bit) is encoded in the module’s memory section and is validated on instantiation; changing it would require a new module.
As of late 2025, memory64 is still outside the stable core specification. It is available only behind experimental flags in the major runtimes:

Wasmtime: --wasm-features=memory64
V8 (Chrome/Node): --experimental-wasm-memory64
Wasmer: --enable-memory64

To target memory64, compilers must use a 64‑bit triple, for example:

Clang: -target wasm64-unknown-unknown -Oz
Rust nightly: -C target-feature=+memory64 (or wasm64-unknown-unknown target)

Verification steps:

Compile a minimal source with the 64‑bit target (e.g., clang -target wasm64-unknown-unknown -nostdlib -Wl,--no-entry -Wl,--export-all -o mem64.wasm mem.c).
Inspect the module: wasm-objdump -x mem64.wasm – the memory section should show limits expressed as i64 values.
Instantiate with the appropriate flag, e.g., wasmtime --wasm-features=memory64 mem64.wasm and call an exported function that returns memory.grow(0); the result will be an i64 representing the current size in pages.
Repeating the same steps with a wasm32 target and attempting to run the wasm64 module without the memory64 flag yields a validation error about an unknown memory type, confirming the compile‑time nature of the model.

Pagination under memory64
Guest‑language pagination that uses byte offsets and lengths works the same conceptually, but the values must be treated as 64‑bit integers:

Offsets and lengths should be stored or passed as i64.
Pointer arithmetic (e.g., base + offset) must be performed with 64‑bit addition to avoid truncation.
Bounds checks compare the computed address against the memory size (memory.size() * 64 KiB) using 64‑bit operations.
No change in algorithmic structure is required; only the width of the integer operations changes.

WebAssembly memory64: 32-bit to 64-bit linear memory compatibility boundary

1 answer

Answer

Confirmed facts

Pagination under memory64

Your perspective belongs here.

0 question comments