We need some basic heuristics for deciding whether a script is too large to compile with IonMonkey.
First, local and argument counts should be capped to something relatively small (probably 256 is okay, 512 might be pushing it - we can measure).
Second, if a JSScript gets recompiled too many times, we should stop trying to optimize it (unless useCount gets reset).
Last, we should have some heuristic for detecting when a function is super expensive to compile, because then if it recompiles at all we'll probably lose.
In all of these cases for now we can fall back to JM+TI.
Created attachment 627206 [details] [diff] [review]
This patch caps script->length and the number of locals + args. It seems to work pretty well.
On Kraken, this helps audio-beat-detection, other tests are unaffected:
beat-detection: 2.18x as fast 435.6ms +/- 2.9% 200.2ms +/-
Score (version 6): 3843
Score (version 6): 4347
SS score does not change much, although we de do reject the large scripts in 3d-cube and crypto-m5. 3d-cube gets 3 ms faster and md5 1 ms slower. Both are still slower than JM+TI, I will look into this now.
What is the impact on emscripten generated code ? misc-bugs-654410-nezulator seems to suffer a lot from this modification.
(In reply to Nicolas B. Pierron [:pierron] from comment #3)
> What is the impact on emscripten generated code ?
I tested sqlite.js and it runs fine now.
> misc-bugs-654410-nezulator seems to suffer a lot from this modification.
I forgot to mention this, but the AWFY regressions are expected: we now reject large scripts and JM is disabled on AWFY. Enabling JM should fix the regressions.