WASM GC: Avoid using array.new_fixed to allocate arrays over 10000 elements

[lax1dude]

I got my app compiled to WASM GC with my own WASM heap direct buffer implementation, but Chrome complains when I try loading the file via WebAssembly.compileStreaming that it’s attempting to create a 17626 element array using array.new_fixed and that the limit for creating arrays like this is 10000 elements.

Uncaught (in promise) CompileError: WebAssembly.compileStreaming(): Compiling function #37428 failed: Requested length 17626 for array.new_fixed too large, maximum is 10000 @+6497484

Turns out its because the string pool and some other initialization code uses it, and my app is so absolutely massive that is has too many strings. I was able to fix this on a new branch in my fork and then actually compile my app to a valid WASM binary that can be loaded in Chrome, however I'm not spend time making a pull request for this unless you are actually interested.

master...lax1dude:teavm:array-new-fixed-patch

[konsoletyper]

I think this patch is excessive. In normal code there's only small chance the we ever reach this limit (we would rather reach method instruction count limit before that). So the only practically possible case is string pool initialization. For that case the solution is simple: just cut entire string list into chunks of at most 10000 elements and pass each one to teavm@initStrings.

[lax1dude]

I see, that would probably also make a smaller binary. I guess I'll eventually redo it when I have time. I think the reason I got my mind set on just replacing all usages of WasmArrayNewFixed was because I wasn't sure if the string pool was the only array that was too big.