Implementation limits

[eqrion]

This was discussed in the CG meeting. The spec should be extended to have new entries for possible implementation limits around extended constants [1] and the JS-API should specify what those limits are for JS embeddings [2].

I propose a limit of 10000 bytes for the size of a initializer expression. But I'm interested in hearing if this is already surpassed by GC proposal users. @tlively do you know if that's the case?

[1] https://webassembly.github.io/spec/core/appendix/implementation.html
[2] https://webassembly.github.io/spec/js-api/index.html#limits

[tlively]

IIRC V8 had a placeholder limit of 1000 values on the stack and @askeksa-google was running into that limit using array.new_static in global initializers. I don't remember whether V8 raised the limit at that point or if @askeksa-google went with a different implementation strategy.

I suspect that users will want to push array.new_static to its limit in global initializers, but will usually need a fallback strategy for cases where that limit would be exceeded. That means that the precise value of the limit shouldn't matter too much, except that higher is better as far as producers are concerned. To make it possible to figure out where that switchover in compilation strategy should be, it would be easiest if the constraint on array.new_static could be specified in terms of values on the stack, i.e. in terms of array length.

If we additionally want a limit on the byte length of initializers, it should be high enough that it is not possible to reach with an array.new_static initializer (or any other constant expression, which makes me think that a byte limit on expression size wouldn't be necessary if we had limits in terms of stack size.)

[titzer]

I think we should not have too[1] small a limit on initializer expressions. For example, Virgil generates binaries that include a full initialized heap snapshot. When targeting the JVM, it generates code that creates that initial heap snapshot. It's now routine to exceed the 64KB method size limitation of the JVM, and that's a pain because the compiler must split the initialization across multiple functions. Virgil runs on Wasm linear memory now, so this is no issue for data segments, but when ported to Wasm GC it would be unfortunate to have to do the same workaround as the JVM.

[1] I do agree there needs to be a limit though. IIRC we have a limit on the total size of a module, so initializers should be an appreciable fraction of that.

[askeksa-google]

The limitation that I ran into for dart2wasm was the limit of 10000 elements for array.new_fixed. We have a workaround for that limit, for the rare case of very big list constants (or long strings). I would be wary of lowering this limit further, as this would induce many more cases of the workaround triggering.

A byte limit for initializer expressions would be difficult to work around for producers, since the byte size of an initializer is difficult (or, at best, cumbersome) to predict before generating it. If we must have one, I'd say that a reasonable size would be the same as the limit on the size of a function body, which is 7654321 bytes.

[eqrion]

I think we can add a length limit for array.new_fixed in the GC proposal, and would support that. However, you can nest that for exponential blow-up and so I think we should also have a byte length limit on the total init expression size.

If it seems like 10_000 bytes is too small, we can probably go with the function body limit of 7654321 bytes. There's a nice symmetry there.