Wasmtime GitHub notifications bot (Oct 04 2026 at 14:42): Wasmtime GitHub notifications bot (Oct 04 2026 at 14:42):simolus3 opened issue #14523:
Feature
Wasmtime supports 1-byte pages for linear memory via the custom-page-sizes proposal, but the GC heap wasmtime uses unconditionally needs 64KiB pages for its backing memory.
Benefit
The motivation for that proposal includes:
Allow Wasm to better target resource-constrained embedded environments, including those with less than 64 KiB memory available.
This is an environment I want to target, except that my modules use GC instead of linear memory.
Implementation
Given that linear memories already support 1-byte pages, adding a tunable + config to support this for GC heaps as well isn't that complicated. While testing, I noticed a few issues where the bytes to grow the heap didn't take alignment into consideration. This is masked by 64KiB pages, but requires minor extra fixes.
Alternatives
Maybe there could also be an option to supply a pre-allocated buffer to use as a GC heap instead; that is generally easier to allocate at once. But given that the buffer would likely not have a multiple of 64KiB as a size, I think we still need one-byte pages for that.
Wasmtime GitHub notifications bot (Oct 04 2026 at 14:42):simolus3 edited issue #14523:
Feature
Wasmtime supports 1-byte pages for linear memory via the custom-page-sizes proposal, but the GC heap wasmtime uses unconditionally needs 64KiB pages for its backing memory.
Benefit
The motivation for that proposal includes:
Allow Wasm to better target resource-constrained embedded environments, including those with less than 64 KiB memory available.
This is an environment I want to target, except that my modules use GC instead of linear memory.
Implementation
Given that linear memories already support 1-byte pages, adding a tunable + config to support this for GC heaps as well isn't that complicated. While testing, I noticed a few issues where the bytes to grow the heap didn't take alignment into consideration. This is masked by 64KiB pages, but requires minor extra fixes.
I'm happy to open a PR for this if this sounds like a feature worth having.
Alternatives
Maybe there could also be an option to supply a pre-allocated buffer to use as a GC heap instead; that is generally easier to allocate at once. But given that the buffer would likely not have a multiple of 64KiB as a size, I think we still need one-byte pages for that.
Wasmtime GitHub notifications bot (Oct 04 2026 at 22:59):alexcrichton added the enhancement label to Issue #14523.
Wasmtime GitHub notifications bot (Oct 04 2026 at 22:59):alexcrichton added the wasm-proposal:gc label to Issue #14523.
Wasmtime GitHub notifications bot (Oct 05 2026 at 21:31):pchickey commented on issue #14523:
Tagging @fitzgen
Wasmtime GitHub notifications bot (Oct 06 2026 at 23:09):fitzgen commented on issue #14523:
Adding a tunable+config knob for the GC heap page size seems reasonable to me.
The most conservative thing to do would be to only allow 1B and 64KiB page sizes. However, we could in theory allow for any power of two (e.g. the platform's natural page size), but this would require checking that all of our memory growth and size and all that code handles this correctly (which it generally should, modulo a few asserts that would become outdated). Easy to do the conservative thing first and the other bit after that.
Maybe there could also be an option to supply a pre-allocated buffer to use as a GC heap instead
I think that we use the
MemoryCreator, if one is configured, for GC heaps' memories. If we don't we should. But either way, the page size changes code generation (which bounds checks can be elided or not) so bringing your own memory on its own is not enough.
Last updated: Oct 11 2026 at 02:20 UTC