View source for Javascript:SpiderMonkey:StartupCache

{{OutdatedSpiderMonkey}} 
== Project ==

=== Motivation ===

Based on Haida prototype, Gaia would be refactored for maintainability &
memory reasons.  The goal of the refactoring is to go from one page, which
was loading JavaScript sources lazily (by appending script tag to the
document), to multiple pages, which are each loading only the set of needed
scripts that they want.

The side effect being that other pages will likely load and execute again
code which was present in a previous runtime, and in addition, they will
load scripts which are uniq to this new page.  This implies that the
transition time to a panel would be increased as we have to load extra
scripts and do extra execution, compare to what used to be done.

One way the JavaScript engine can improve both the transition time and the
start-up time of applications (as a transition is becoming some sort of
start-up), is to remember the information which is needed for starting the
application and to prevent loading the sources during the start-up of the
application. That way, we will load less information at the beginning and we
should be able to skip the CSP & the validation process & binding generation
and start executing the cached bytecode.

=== Goal ===

The goal is to define a cutting point at which we will start generating
"extra data" which contains data using less space than the source and
contains the bytecode of all functions used during the start-up (less than
25%) and contains the lazy-scripts of all other functions.

The idea being that we can store "extra data" as large as the source, or
less, while reducing the number of operation on the ciritical path of the
start-up (checking CSP, checking script validity, generating bindings). This
way the source is optional (and thus can be loaded outside the critical
path) until we reach the cutting-point or we are explicitly asked for it
with toSource.

Most (all?) JSScript used in the applications are compile-and-go
applications.  We need to instrument XDR, such as we can encode and decode
compile-and-go scripts and re-link the bytecode (see [https://bugzilla.mozilla.org/show_bug.cgi?id=288473&c=7 Bug 288473 comment 7])
to substitute the embedded global.

We can experiment this on sunspider/kraken benchmarks by looking at the
effect by implementing a dummy cache as part of the load JS-Shell function
to confirm the expected speed-up.

Then we will need to make this work with the ScriptLoader, and add an extra
data cache to packaged-app, app-cache and the http-cache (see [https://bugzilla.mozilla.org/show_bug.cgi?id=900255 Bug 900255]).

Tracking Bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=900784 Bug 900784]

=== Roadmaps ===

The refactoring of Gaia applications is planned for 1.4. (see Haida roadmap)

* Gaia Roadmaps: https://docs.google.com/spreadsheet/ccc?key=0AmStZDZgJbV7dDhtMDZlQmRtdDB4a1plZXRwNXIzYWc#gid=0
* Haida Roadmap: https://wiki.mozilla.org/FirefoxOS/Haida

== Related Work ==
* [https://bugzilla.mozilla.org/show_bug.cgi?id=900255 Bug 900255]: Support new API for reading/writing "extra" data for cache entries

== Similar Work ==

* [https://bugzilla.mozilla.org/show_bug.cgi?id=883154 Bug 883154]: Share scripts amond compartments which are part of the same runtime. This optimization only works within the JS Engine and does not prevent execution of the CSP nor loading the source. Also it does not work for workers which might load the same scripts as the worker has its own runtime.

* [https://bugzilla.mozilla.org/show_bug.cgi?id=813324 Bug 813324]: Profile the cost of caching all the bytecode (before the lazy script implementation) on a desktop, and profile what time it takes to load the bytecode compared to loading the source by doing it purely on the JS side.  This show that we can save hundreds of milli-seconds on large scripts (of 2.5 MB of bytecode) such as the one provided by drive.google.com on a desktop.

* [https://bugzilla.mozilla.org/show_bug.cgi?id=679939 Bug 679939]: Suggest removing COMPILE_N_GO optimization in favor of caching the bytecode. This bug can be worked around during the development of the JS Cache by providing a re-link phase to the XDR Decoder as suggested in [https://bugzilla.mozilla.org/show_bug.cgi?id=288473&c=7 Bug 288473 comment 7].

* [https://bugzilla.mozilla.org/show_bug.cgi?id=288473 Bug 288473]: Attempt to do a cache implementation for JS and reports that the bytecode saved by XDR has way more overhead than the minified sources.