Javascript:SpiderMonkey:StartupCache

	THIS PAGE IS OBSOLETE
	This article is in parts, or in its entirety, outdated. Hence, the information presented on this page may be incorrect, and should be treated with due caution. Visit SpiderMonkey.dev for more up to date information.

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 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 Bug 900255).

Tracking Bug: 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

• Bug 900255: Support new API for reading/writing "extra" data for cache entries

Similar Work

• 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.

• 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.

• 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 Bug 288473 comment 7.

• 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.