1357884 - Pre-generate and cache the most common optimized Baseline IC stubs

Status: NEW

(Core :: JavaScript Engine: JIT, enhancement, P3)

Description

[Kannan Vijayan [:djvj]]

We currently generate and cache optimized baseline IC stubs at the point-of-first-use.

There are many common baseline IC stubs that are guaranteed to be used on most pages.  If we can identify these through some basic instrumentation, we can try to pre-generate (asynchronously, background thread) these IC stubs and cache them, ensuring that they are present by the time we need them.

This should help page load performance.

Comment 1

[Kannan Vijayan [:djvj]]

Additionally, the TypeCheck_* and TypeUpdate_* stubs should all be pre-generated - they'll definitely be used heavily on every page.

We also want to put the generated code for these (the raw machine code, not the actual JitCode* objects), contiguously in some bump-allocated memory, with an eye towards memory locality.

For example, we know that the TypeCheck_* stubs will typically be called in quick succession.  The code for these stubs is also quite small.  If we can lump them all together in memory, we have a better chance of multiple sequential stubs sitting on the same cache line, and an even better chance that at least they'll be in the same page (leading to lower TLB pressure).

Comment 2

[Shu-yu Guo [:shu]]

Reprioritize if we have data.

Comment 3

[Nicolas B. Pierron [:nbp] {away}]

One alternative that we could use as a way to pre-generate is to save the Baseline IC stubs next to the self-hosted stencil code, which is stored in a file while running the test suite, and generated by the parent process when running Firefox.

This has the advantage of avoiding the question of changing the build process, especially around the corners of cross-compilations.

Comment 4

[Mayank Bansal]

Could this be done now with OMT Baseline compilation enabled?

Comment 5

[Iain Ireland [:iain]]

This is still vaguely on a long-term roadmap, but mostly unrelated to OMT baseline compilation. Some of the infrastructure for capturing the set of important ICs was written for PBL (bug 1855321), although I don't recall whether that part actually landed in-tree. We might be able to reuse some of Bryan's self-hosted caching infrastructure here again, if we decide to go with runtime-wide ICs.