I hope this is the right place to ask for help on this.
I started looking into WasmGC memory limits after some community reports.
From the initial investigation I found the spec acknowledges GC limits (struct/array instance counts, array size) in the implementation limits appendix but leaves them implementation-defined with no mandatory values.
What other runtimes do:
array.new_fixed operands at validation timeThe 10,000 limit only applies to array.new_fixed (compile-time), not dynamic array.new, though compilers like TeaVM and Dart have already hit this ceiling with string pools and constant tables.
Am I overlooking anything in the spec? And more broadly, is a fixed global max really the best approach?
AFAIK engines generally try to all agree on these limits so if they're inconsistent that's probably a bug worth raising, although dynamic limits like heap size are probably less consistent (as seen)
if they're inconsistent
AFAIU the "implementation limits appendix" is not normative, I went ahead and tested things on a few runtimes and behavior seems to be, at the very least, not consistent.
a bug worth raising
In the spec repo or somewhere else?
for the records, caused by this research, I found this bug and reported with the hope to get more eyes and thoughts on the subject too
I'm not sure myself how best to get the attention of other engines, but bugs-on-engines seems like a reasonable way to get started yeah
I know in the past engines have tweaked the limits' definitions to match each other and also updated implementations to match others' limits, mostly because as you're seeing the inconsistent experience can be confusing and difficult to work with
Maybe I'm overlooking something, but, in this case, seems like a definition of a limit(identified as a pure global number) fall very short in a lot of scenarios.
When running on a microcontroller I'd like to be able to impose a very restrictive limit, while, maybe, in Java or other GC'd runtimes I'd like to allow allocating as long as the JVM has available heap(I have seen JVMs running with 32/64Gb of dedicated memory)
oh sure yeah, that's where these will never be normative but you should probably still have the same limits across "big beefy machine can run everything"
What I'm questioning is if having "just a number" is really the only option we can hope for.
When a user can crash the host from inside the sandbox, I hope the answer will be more articulated than an afterthought.
FWIW, in Wasmtime this would be a CVE, so should you find something like this, please report it privately :slight_smile:
more generally, regardless of how it's handled exactly, for most engines allocation attempts by guest code shouldn't be able to trigger a runtime crash. Though I know that browsers by now to some degree treat the content process as the blast zone, I doubt they'd treat this as expected behavior either
Last updated: Aug 30 2026 at 09:07 UTC