1363562 - Speed up parsing and baseline compilation by saving information across page visits

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, enhancement, P3)

Description

[Brian Hackett [Laid off!]]

Complicated web pages execute a lot of JavaScript, and we spend a lot of time parsing and compiling that JavaScript so that we can execute it.  A couple weeks ago I used the trace logger to measure the amount of time we spent in various parts of the JS pipeline on the main thread when loading the facebook news feed and scrolling down for a bit.  Here's the breakdown I got:

Baseline: 43.7%
IonMonkey: 25.4%
Interpreter: 10.8%
GC: 5.3%
BaselineCompilation: 3.7%
IonCompilation: 3.7%
MinorGC: 2.2%
ParsingFull: 1.8%
BytecodeEmission: 1.6%
IonLinking: .6%
IonAnalysis: .4%
ParsingSyntax: .3%
IrregexpCompile: .2%
IrregexpExecute: .2%

I also instrumented a browser to keep track of parse and baseline compilation events, and found that when visiting facebook multiple times about 80% of the scripts (weighted by their size in the script source) that are lazy-function-parsed or baseline compiled in later visits were also parsed/baseline-compiled in the previous visit (scripts are equal here if they are at the same place within identical script sources).  The ordering of parse/compile events is similar between visits but not exact.  I repeated this experiment on gmail and got similar numbers.

It would be neat if we could save information between visits of the same page so that subsequent visits have clues about what is likely to execute on the page and can perform work off thread in anticipation of that potential behavior.  When the main thread first executes a function and needs to lazy-parse it, the off thread task will hopefully have already done that parsing and produced a usable script.  If the function might become hot enough to baseline compile, then the off thread task will hopefully have already baseline compiled it, and the main thread can skip both baseline compilation and interpreter warmup.

The potential main thread time we could eliminate would be ParsingFull + BytecodeEmission + BaselineCompilation + some percentage of Interpreter.  I don't know what percentage of our interpreter time is spent on scripts that we'll eventually baseline compile, but I'm guessing it's between 20% and 50%.  If baseline execution is far faster than interpreter execution then that percentage of interpreter time would be pretty much wiped out.  That means the maximum percentage of main thread time saved with 80% prediction would be (1.8 + 1.6 + 3.7 + (10.8 * .2 to .5)) * .8, or 7.4% to 10%.

The next step here is I think to build a mockup that avoids the question of how to store this cached information and just pulls the info from an ad hoc local file.  I need to see how close we can get to the above ceiling before we can know whether this idea is worth pursuing.  The basic design would be to start an off thread task when lazy parsing a script source, which does full parses of functions in the source that are likely to execute and baseline compilations of scripts that are likely to warm up enough for baseline compilation.  When the main thread needs to parse or baseline compile a script it tries to incorporate one that was performed off thread.  There are some threading issues to address (e.g. the incorporating might be done while the off thread task is busy, and the off thread task is baseline compiling against a global that might be in use by the main thread) but I don't think they will be too complicated.

I don't know what the right relationship between this bug and bug 900784 is, and AFAICT the bytecode cache does not trigger at all on facebook (maybe due to constraints related to off thread parsing, or maybe I'm not measuring it right).  Regardless, the same threading issues as above exist whether we are parsing or XDR'ing scripts off thread for use by the main thread.

Comment 1

[Matthew Gaudet (he/him) [:mgaudet]]

This is being addressed piecemeal elsewhere; e.g. Stencil & jit-hints.