JSBC: JavaScript Start-up Bytecode Cache

Nicolas B. Pierron nicolas.b.pierron at mozilla.com
Tue Jun 13 09:50:08 UTC 2017


The JavaScript Start-up Bytecode Cache⁰ is a project which aims at reducing 
the page load time by recording the bytecode generated during the last 
visits and by-pass the JavaScript parser.

This project changes the way we process JavaScript script tags which are 
fetched from the network, and cached. After multiple visits¹, the bytecode 
would be encoded incrementally², as soon as the bytecode emitter generates 
it. Once we reached some idle time³, we save the content encoded 
incrementally as an alternate data on the cache⁴.  The cache contains a 
compressed version of the source, the bytecode of functions which got 
executed during the start-up of the page, and all non-executed functions 
encoded as source indexes⁵.

On follow-up visits the script loader would load the alternate data instead⁶ 
of the source, and decode the bytecode either off-thread⁷ or on the 
current-thread.  This is expected to replace the syntax checker and the 
bytecode emitter for all recorded functions.

This feature is currently pref-ed off and can be enabled by setting the 
following preferences in about:config⁸:
   - dom.script_loader.bytecode_cache.enabled = true
   - dom.script_loader.bytecode_cache.strategy = 0

For any issue caused by this optimization, filed it as a blocker of Bug 900784.

In the upcoming days, I will add telemetry probes to better tune the 
heuristics¹ for the web and monitor the known sources of fallback and 
failures. In addition, I will request for a pref-experiment, such that we 
can get more data from nightly users. At the moment, I expect to enable this 
feature around mid-July.

⁰ https://bugzilla.mozilla.org/show_bug.cgi?id=900784
¹ These are heuristics which would be customized by running a 
pref-experiment. (see https://bugzilla.mozilla.org/show_bug.cgi?id=1362114)
² We cannot do it off-thread, nor after the execution (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1316081)
³ Currently set to the next cycle after the processing of the OnLoad event. 
(see https://bugzilla.mozilla.org/show_bug.cgi?id=1372207)
⁴ Thanks to Valentin Gosu for his work and support on the alternate data 
interface as part of necko. (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1231565)
⁵ https://bugzilla.mozilla.org/show_bug.cgi?id=917996
⁶ This forces us to store the compressed source as part of the encoded 
bytecode, but prevent additional round-trip between the parent and child 
processes.
⁷ https://bugzilla.mozilla.org/show_bug.cgi?id=1316078http://searchfox.org/mozilla-central/rev/d840ebd5858a61dbc1622487c1fab74ecf235e03/modules/libpref/init/all.js#212-233

-- 
Nicolas B. Pierron


More information about the dev-platform mailing list