1490849 - Off-Main-Thread Baseline Compilation

Status: NEW

(Core :: JavaScript Engine: JIT, enhancement, P2)

Description

[Sean Stangl [:sstangl]]

Baseline compilation is single-pass and intended to be quick: therefore we currently block execution and compile on the main thread. But, particularly when executing small functions, the combination of Baseline compilation and the mprotect() call during linking wind up blocking the main thread for an excessive amount of time. That seems to be the culprit for comparatively poor performance in real-world code (for example, Bug 1363383) relative to Chrome.

Because Baseline doesn't freeze typesets, it would be feasible in the near-term to move Baseline compilation and linking off of the main thread.

My understanding is that Chrome already does this, and this is the reason why their profiles do not show Baseline-equivalent compilation pauses.

Comment 1

[Mayank Bansal]

Is this bug worth reexamining now?

Comment 2

[Ted Campbell [:tcampbell]]

That is an interesting question. I'm going to block this on Bug 1812157 where we will better study how the latency of moving the compile off-thread affects things.

Comment 3

[Iain Ireland [:iain]]

One interesting point in design space, designed to let us amortize our mprotects over more compiles without getting stuck waiting: when we decide to do a baseline compile, we put it in a queue for an offthread task. The offthread task grabs it and generates native code in a buffer. When it's done, it checks to see whether there's another baseline compile queued up. If there isn't, we go ahead and link the existing code. If there is, and the amount of code in the buffer hasn't exceeded a threshold, then the background task keeps compiling code until we run out of space or queued up tasks.

Comment 4

[Jan de Mooij [:jandem]]

I think the most interesting problem to solve for off-thread Baseline + batching is how to do the off-thread mprotects in a way that doesn't waste a lot of memory (because the main thread can be executing JIT code, you can't reuse pages as easily). A good solution for that could potentially also be used for IC code, if it matters.

Since this bug was filed, we've reduced the number of Baseline compilations and made them faster, so it would be good to remeasure this.

Comment 5

[Iain Ireland [:iain]]

I am working on this. The mprotect problem has been circumvented by removing mprotect in content processes.

I have a preliminary version of baseline batching, but post-mprotect-removal it doesn't meaningfully improve performance. I am optimistic that moving the compilation of a batch off-thread will be an improvement. Building it on top of batched baseline compilations helps us keep the thread dispatch overhead down.

Once I get to the point where it matters I am going to try doing as much of the linking process offthread as I can. If that works out, we can consider moving more Ion linking offthread as well.

Comment 6

[Iain Ireland [:iain]]

js-perf-next: Finish implementing this.