542144 - package and ship already JIT'd chrome JavaScript

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Dietrich Ayala (:dietrich)]

Beltzner suggested this today. Can someone comment on the viability of this idea?

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

For trace-compiled scripts, this would be extremely difficult. We bake in all sorts of run-time addresses and goodies into traces that would need to be relocated. Once JägerMonkey is in gear it could be easier to cache whole method compilation results.

Out of curiosity, how much time is actually spent compiling JS on load?

Comment 2

[Robert Sayre]

yeah, need numbers on how long things take now.

Comment 3

[Andreas Gal :gal]

Discussed this with sayrer. I have been interested in this for a while. I think from a technical perspective, chrome can be compiled well to native code statically for the most port. We should see a speedup to JIT-level and beyond if we use a backend like LLVM. Latency should improve too. However, code size will definitely go up. We should measure by how much. I wouldn't be surprised by 10x or so. So the trade-off here is latency/speed vs code size. How much does JS execution contribute to our frontend startup and execution time? We should shark that. sayrer suggested estimating the total speedup by assuming we can make JS infinitely fast. I think thats a good idea. Any volunteers?

Comment 4

[Dietrich Ayala (:dietrich)]

See bug 522354 for some initial work into figuring out why and where js_Execute spends time.

Comment 5

[Nicholas Nethercote [inactive]]

(In reply to comment #3)
> Discussed this with sayrer. I have been interested in this for a while. I think
> from a technical perspective, chrome can be compiled well to native code
> statically for the most port. We should see a speedup to JIT-level and beyond
> if we use a backend like LLVM. 

Sounds complicated.  We currently have two JS implementations, the interpreter and the tracer.  Work is being done on a 3rd, JaegerMonkey.  Would this be a fourth?

Comment 6

[Brendan Eich [:brendan]]

Life is complicated, especially if you are implementing JS in a browser, going against V8 and JSC, and with your cross-platform UI and widgets including HTML ones scripted using JS to boot.

We do not have separate JS implementations in interpreter and tracer and JM. A JS implementation consists of compiler too, and the bytecode interpreter, tracing JIT, and inline/call-threaded JIT (JM) are all part of one implementation. They share common data structures including GC.

The JM plan, not at first but eventually and soon enough, is to replace the old bytecode interpreter. So that will help.

An ahead-of-time compiler for chrome JS we ship is another mouth to feed, and more properly speaking a second JS implementation. Still might be worth it, but comment 3 may be underestimating code bloat issues.

Comment 4 points to analysis we need to do to make sure we know what we are optimizing. But static analysis of JS, for type inference mainly -- and then traditional AOT optimizations -- could be good.

/be

Comment 7

[Marco Castelluccio [:marco]]

We could compile the JS code in the browser into the intermediate representation used by our JS engine.
This would eliminate some compiler passes (parsing and some optimizations).

Comment 9

[Tihomir]

The PyPy project used some interesting tricks with program specialization (lookup Futamura projections). I was thinking - wouldn't it be simpler to construct a AOT JS compiler via this method, in haskell, than retrofitting something already retrofitted for another purpose. GHC is already among the most performant high-level language compilers, piggybacking on it might actually be smarter than reusing JIT components, which factor in optimization cost.

Comment 10

[Florian Bender]

How about a chrome JS-as-AST cache packed in one file (for reducing FS latency) that is generated on install and update? AFAICS this would be a pre-compiled omini-jar?

Comment 11

[David Teller [:Yoric] - still alive but not very active]

Tihomir: I suspect that adding and maintaining a second compiler written in a second programming language, even if that language is Haskell, would complicate things considerably.

Florian: I seem to remember that parsing is not an important cost. I suspect that a stored AST would also be much larger than the source code, hence increasing FS latency.

Comment 12

[Mayank Bansal]

Is this already done with hte different caches and script loaders today?

Comment 13

[Iain Ireland [:iain]]

I don't typically see chrome JS (as opposed to content JS) show up in profiles. I don't know if that's a matter of looking in the wrong place?

I asked in #spidermonkey about stencil caching for chrome JS, and arai replied:

which chrome JS specifically? there are multiple caching mechanism
some of them may be the target of startup cache, or script preloader, or maybe not target of anything but just excluded by the upcoming scriptloader cache (because of being local file)
StartupCache covers:

• JS used by XUL
• system ESM (ChromeUtils.importESModule etc)
• subscript (Services.scriptloader.loadSubScript etc)
• self-hosted JS
• and some other non-JS, such as font

ScriptPreloader covers:

• frame script (mm.loadFrameScript etc)
• process script (ppmm.LoadProcessScript etc)
• system ESM (ChromeUtils.importESModule etc)
• subscript (Services.scriptloader.loadSubScript etc)

The upcoming cache for the DOM ScriptLoader targets the web contents. ScriptLoader is used also by some chrome-priv code, but those scripts are excluded by the target.

If we're already caching stencils for most of the important chrome JS, and we're not seeing hotspots in chrome JS where we really want to be in higher tiers sooner, then I don't think it's worth putting a lot of additional effort into additional caching here. (The exception is self-hosted JS, which does show up frequently in profiles; to help with that, Bryan is about to land a patch stack in bug 1827914 to use an in-memory cache to share baseline-compiled code across a runtime.)

Comment 14

[Mayank Bansal]

FWIW, this is a samply profile of startup of my regular Firefox profile : https://share.firefox.dev/43iASu1
The parent-process appear to spend a lot of time around JS/GC. Is that the same thing as what this bug (ans stencil) aims to improve?

Comment 15

[Iain Ireland [:iain]]

Am I looking in the right place? I see 77/1671 samples in the parent process being spent in JS, which is just under 5%. In particular, the fact that only 3 samples are in Ion implies to me that very little JS code gets hot in the parent process during startup; if it's mostly glue code, then stencil caching is probably good enough.