706914 - JM: Compile large scripts in chunks

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Brian Hackett [Laid off!]]

Attachment: WIP (c4832f2d9986)

There's a longstanding problem with JM+TI (and any engine that combines both whole method compilation and invalidation/recompilation) where too much time is spent compiling large scripts.  The amount of time to compile a script is linear in its size (optimistic, but seems to hold in practice) and the number of times a script needs to be recompiled is also expected to be linear in its size, all else being equal.  This leads to quadratic behavior which really hurts when dealing with large scripts.

This can be helped (not sure if fixed) by not doing whole method compilation, but rather compiling scripts in chunks.  Pick an arbitrary partitioning of the script into chunks, only compile one chunk at a time and keep track of cross-chunk edges to fix up after doing a compilation or discarding a chunk due to a recompilation.  The attached patch (WIP) does this, still needs more work to not be broken.

Comment 1

[Brian Hackett [Laid off!]]

Attachment: WIP (c4832f2d9986)

Passes jit-tests -mna with a chunk size of 10 ops (for stress testing).

Comment 2

[Brian Hackett [Laid off!]]

Attachment: WIP

Wrong patch attached earlier.

Comment 3

[Brian Hackett [Laid off!]]

Attachment: patch (c4832f2d9986)

Working patch, needs a rebase.

Comment 4

[Brian Hackett [Laid off!]]

Attachment: patch (61a46d539c69)

Patch rebased to tip.  The CHUNK_LIMIT environment variable is in place for testing, when this lands it will be hardcoded to something else (like 1000).

Comment 5

[Brian Hackett [Laid off!]]

Decoder, Gary: can you guys fuzz this patch some?  It is a significant method JIT change.  Beforehand, you should set the CHUNK_LIMIT environment variable to some smallish value, between 5 and 100 say (this controls how scripts are partitioned during compilation).  The testing should mainly be done on x86, as this functionality is totally disabled on x64 (for now at least, and possibly for the lifetime of JM).  I can also make the chunk limit controllable from the shell with a chunkLimit(N) function if that would make things easier, and will probably take this route anyways when landing the patch.

Comment 6

[Brian Hackett [Laid off!]]

Attachment: patch (b121a045b451)

Rebased, removes CHUNK_LIMIT environment variable and allows the chunk limit to be changed in the shell with mjitChunkLimit(N).

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

> least, and possibly for the lifetime of JM).  I can also make the chunk
> limit controllable from the shell with a chunkLimit(N) function if that
> would make things easier, and will probably take this route anyways when
> landing the patch.

Adding the chunkLimit(N) function will likely be really useful. :)

Comment 8

[Christian Holler (:decoder)]

I'm on it, will file bugs blocking this one when I have results.

Comment 9

[Brian Hackett [Laid off!]]

Attachment: patch (b121a045b451)

Updated with fixes for dependent bugs.

Comment 10

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

> Created attachment 583509 [details] [diff] [review]
> patch (b121a045b451)
> 
> Updated with fixes for dependent bugs.

fwiw, this patch has bitrotted, it would be nice to have a rebase. :)

Comment 11

[David Anderson [:dvander] - inactive, e-mail if emergency]

Comment on attachment 583509 [details] [diff] [review]
patch (b121a045b451)

Review of attachment 583509 [details] [diff] [review]:
-----------------------------------------------------------------

There's not a whole lot I can do to review this patch but I do have one suggestion with regards to IonMonkey compatibility:

::: js/src/jsinfer.h
@@ +1125,5 @@
> +struct RecompileInfo
> +{
> +    JSScript *script;
> +    bool constructing:1;
> +    uint32_t chunkIndex:31;

It would be much nicer if this structure could be:
    JSScript *script;
    jsbytecode *pc;

And then have processPendingRecompiles do the work of finding the chunk index in the ctor and non-ctor JITScripts. Currently, IonMonkey doesn't do chunked compilation (and won't in the next few months); doesn't have constructor bifurcation; it might end up having a different chunking approach too. So having a more generic interface would be ideal.

Comment 12

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d0c192e5bd41

Comment 13

[Brian Hackett [Laid off!]]

Oh, for integrating this into IM, just use constructing == false and chunkIndex == 0.  The script/constructing/chunkIndex are just identifiers for a compilation unit, and JM/IM do not track dependencies at such a fine granularity as the pc.

Comment 14

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

https://hg.mozilla.org/mozilla-central/rev/d0c192e5bd41