Wasmtime GitHub notifications bot (May 22 2025 at 13:15): Wasmtime GitHub notifications bot (May 22 2025 at 13:15):sammyne opened issue #10824.
Wasmtime GitHub notifications bot (May 22 2025 at 13:32):bjorn3 commented on issue #10824:
Heap allocated variables end up in the linear memory of the component. The wasm module itself defines the size limit of the linear memory it creates (up to 4GB for a wasm32 module).
Wasmtime GitHub notifications bot (May 22 2025 at 14:27):alexcrichton closed issue #10824.
Wasmtime GitHub notifications bot (May 22 2025 at 14:27):alexcrichton commented on issue #10824:
In general there's no one heap limit in wasm and/or components. @bjorn3 is right that the abstraction level of a wasm component is the linear memory it places the heap into, which means that you'll be subject to a number of possible limits.
- Guest languages typically don't support any one allocation being larger than 2G. In LLVM, for example, it's UB to have a single allocation larger than half the address space (in this case the address space being 4G). This is not a wasm limitation, but can be a limiation of what you compile to WebAssembly.
- WebAssembly components are predominantly 32-bit meaning there's a hard limit of 4G of memory. It's simply not possible to address more memory since it's outside of the 32-bit address space. At this time there's no support for 64-bit components.
- Runtimes may provide a more stringent limit than the entire 32-bit address space. Wasmtime embedders, for example, may further limit memory of guests to ensure it doesn't eat everything from the host.
- WebAssembly memories can further limit themselves through a maximum size. This is not commonly set but is possible to do so.
I'm going to close this as answered, but if you have follow-up questions please feel free to comment here.
Last updated: Dec 06 2025 at 07:03 UTC