Wasmtime GitHub notifications bot (Aug 12 2025 at 03:37): Wasmtime GitHub notifications bot (Aug 12 2025 at 03:37):alexcrichton opened issue #11417:
When a GC allocation fails in Wasmtime right now the current algorithm is to (a) grow the heap and (b) failing that perform a GC. This means that practically all applications will, by default, grow the entire GC heap to 4GB before any GC actually happens. This has an unfortunate side effect of meaning that we very rarely test GC behavior outside of explicit GC calls right now in tests and fuzzing (otherwise I would presume issues in https://github.com/bytecodealliance/wasmtime/pull/11416 would have been caught sooner?). This additionally means that applications which have a small working set of memory but a large amount of churn will have a very large memory footprint as the heap grows.
I think this is something we'll want to tune over time, but by default I think that a GC should happen with some amount of balance before reaching the limit of linear memory. I'm not sure what a good heuristic is, but I feel that our current heuristic isn't the right default.
Wasmtime GitHub notifications bot (Aug 12 2025 at 03:37):alexcrichton added the wasm-proposal:gc label to Issue #11417.
Wasmtime GitHub notifications bot (Aug 12 2025 at 17:15):cfallin commented on issue #11417:
Perhaps a decent heuristic could be: when we hit the GC heap limit, GC first, then if the heap occupancy after GC is over a threshold (50%? tunable knob?) then grow?
I wonder if this could be a reason that we see large slowdowns in allocation-heavy benchmarks currently: even if growth is in-place (virtual memory-based GC store), growth-first guarantees cache misses on every new object, while a benchmark with a small working set that could fit in cache would otherwise be much happier with address reuse after a GC. (This trades off with the time to do the GC, of course!)
Wasmtime GitHub notifications bot (Aug 12 2025 at 17:22):alexcrichton commented on issue #11417:
That seems reasonable to me yeah. While I'm sure caches are indeed an issue historical profiling has also shown that https://github.com/bytecodealliance/wasmtime/issues/11159 is a major slodown -- basically the allocation algorithm right now is pretty non-optimal.
Last updated: Dec 06 2025 at 06:05 UTC