Closed Bug 755010 Opened 12 years ago Closed 12 years ago

IonMonkey: Address worst-case compile performance on extremely large scripts

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dvander, Assigned: jandem)

References

Details

Attachments

(1 file)

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.
Assignee: general → jdemooij
Status: NEW → ASSIGNED
Blocks: 758268
Attached patch PatchSplinter 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 +/-

V8 before:

Richards: 9761
DeltaBlue: 8179
Crypto: 13756
RayTrace: 977
EarleyBoyer: 2507
RegExp: 495
Splay: 9298
----
Score (version 6): 3843

V8 after:

Richards: 9779
DeltaBlue: 8106
Crypto: 13868
RayTrace: 969
EarleyBoyer: 2428
RegExp: 1202
Splay: 9420
----
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.
Attachment #627206 - Flags: review?(dvander)
Attachment #627206 - Flags: review?(dvander) → review+
http://hg.mozilla.org/projects/ionmonkey/rev/feac7727629c
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
What is the impact on emscripten generated code ?  misc-bugs-654410-nezulator[1] seems to suffer a lot from this modification.

[1] http://arewefastyet.com/?machine=9&view=assorted
(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[1] 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.
You need to log in before you can comment on or make changes to this bug.