[andreaTP]

Fixes #273.

call_indirect dispatch methods had fixed sizes (up to 1024 cases in call_indirect_N, blocks of 4096 ids in Indirect_N_*.apply), so on large modules they went over HotSpot's 8000-byte limit and every indirect call ran in the bytecode interpreter. Their size now comes from endive.hugeMethodLimit, as Machine.call dispatch already does: 128 cases and blocks of 512 at the default limit, the values measured in #273.

This also fixes two bugs on the block path, which this change makes much more common:

• apply loaded arguments by parameter index instead of JVM slot, so a type with an i64/f64 parameter before the last one failed verification. On main this already affects modules with more than 1024 functions of such a type.
• The block size returned by loadChunkedClass, halved on ClassTooLargeException, was ignored.

	before	after
Synthetic, 2000 int(int) functions	92 ns/call	23 ns/call
CPython dispatch methods over 8000 B	8 (max 23 KB)	0
CPython classes / total bytes	34 / 7.85 MB	214 / 7.86 MB

Thanks @JosepMariaBlasco and @ddsimoes for the reproducers and the numbers.

[JosepMariaBlasco]

Thanks for picking this up, and for the credit!

I tried the PR (54e830d) with our ooRexx module, in place of our own compiler patch:

• No call_indirect dispatch method over 8000 bytes any more (with 1.2.0 there were four, the largest 11.5 KB). The only methods still over the limit are three huge Wasm functions, which is Method splitting #270's territory.
• rexxcps: 1.90 M clauses/s, against 1.83 M with our patch and 0.66 M with stock 1.2.0 (same machine, runs alternated).
• ooRexx's test suite: all 405 groups pass (24,440 tests).

So once this is in a release we can drop our patch. Thanks again!

[andreaTP]

Thanks for double checks!