Open Bug 1357884 Opened 7 years ago Updated 1 year ago

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

Categories

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

enhancement

Tracking

()

Performance Impact low

People

(Reporter: djvj, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf)

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.
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).
Whiteboard: [qf]
Whiteboard: [qf] → [qf:p1]
Reprioritize if we have data.
Whiteboard: [qf:p1] → [qf]
Assignee: nobody → kvijayan
Whiteboard: [qf] → [qf:investigate:p1]
Whiteboard: [qf:investigate:p1] → [qf:p3]
Keywords: perf
Priority: -- → P3
Assignee: kvijayan → nobody
Performance Impact: --- → P3
Whiteboard: [qf:p3]
Severity: normal → S3

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.

You need to log in before you can comment on or make changes to this bug.