On 10/17/2014 06:43 PM, Luke Wagner wrote:
I have a short summary of why caching JIT code is not necessarily a clear win
for most JS in a blog post:
http://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/#caching
We do machine code for asm.js, though (as also described in the post).
More interesting than caching machine code is caching other bits of data that
offer a lot more win per byte:
- function boundaries and whether there were any SyntaErrors (so we don't
have to do the initial syntax-only parse)
- bytecode for the top-level script and definitely-run functions (usually
this stuff is pretty cold, so bytecode is as far as it ever gets)
- for the functions that do get jitted: which ones, what types were observed,
etc, so we can expedite the normal warm-up and recompilation process
This involves attaching blobs of "stuff the JS engine wants back next time" to
network cache entries and a whole new path from path from Necko through Gecko to
SpiderMonkey, so it's not exactly a small project :) We've actually done some initial
work in this direction (motivated by b2g app performance):
https://bugzilla.mozilla.org/show_bug.cgi?id=900784
but it seems to be on hold atm. I hope it resumes before long.
This is on hold because B2G no longer use Lazy Scripts, which means that the
intent of it is no longer present for B2G as we are doing a full bytecode
compilation for all certified application, and discard the source for memory
saving issues.
This kind of approach does not only makes sense for JavaScript, but it would
also be interesting for CSS, GFX and other parts of Gecko which can benefit
from caching short-cuts/hints for the next executions. Thus, it would be
better if we can get this well integrated with Necko instead of having
everybody creating their own persistent storage.
--
Nicolas B. Pierron
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
