1818337 - Be more aggressive about JitScripts for off-thread parses

Status: NEW

(Core :: JavaScript Engine, task, P2)

Description

[Ted Campbell [:tcampbell]]

Similar to approach in Bug 1736057, where we generate full bytecode for off-thread parses, we can eagerly allocate JitScripts for those same parses.

The naive way to do this is to leverage the Stencil-Instantiation mechanism to have an additional instantiation option to create the JitScripts as well. This works nicely because we have a full list of JSFunctions in a vector at that point and don't need to do any searching. Using the off-thread parse heuristics lets us avoiding impacting event handlers or evals.

Today the Stencil-Instantiation is on main-thread, but can happen early on during load (such as waiting for network). In Bug 1773339 we are clearing up how all parse-related threads work so there will be more easy opportunities to do more of this off-thread.

JitScripts are getting a lot cheaper to allocate these days, and memory impact is lowered.

As a starting point, we should also subscribe to the 'ContentChild::RecvNotifyProcessPriorityChange' signal to limit this heuristic to foreground processes.

If this is stable enough, we can look at more aggressive jitting of other tiers, though there may be smarter ways to do that then with this blunt hammer.

Comment 1

[Ted Campbell [:tcampbell]]

The browsertime harness is interacting in strange ways so I'm not seeing changes on CI. Locally I see about a 6% improvement for this limited JitScript approach. Pageload also gets 5-10% faster which is a bit surprising, but also leveraging the Stencil structures gives better locality. AWSY shows no impact as expected since we don't quantify transient memory usage.

Comment 2

[Ted Campbell [:tcampbell]]

TODO: Avoid breaking no-jit builds
TODO: Add jsshell flag for evaluate and command line.
TODO: Add dom::ScriptLoader pref for this

Comment 3

[Ted Campbell [:tcampbell]]

Attachment: WIP: Bug 1818337 - Eagerly create JitScripts for off-thread full parses

Comment 4

[Ted Campbell [:tcampbell]]

Attachment: WIP: Bug 1818337 - More jitscript allocation off thread

Depends on D172769

Comment 5

[Markus Stange [:mstange]]

Is this still being planned? Interpreter time is not showing up as a problem on speedometer3, so entering BaselineInterpreter earlier probably wouldn't affect our score, but it still seems like a useful thing to have.

Comment 6

[Nicolas B. Pierron [:nbp]]

I did not know why this bug is assigned to me. I will unassigned my-self in the mean time.

(In reply to Markus Stange [:mstange] from comment #5)

Is this still being planned? Interpreter time is not showing up as a problem on speedometer3, so entering BaselineInterpreter earlier probably wouldn't affect our score, but it still seems like a useful thing to have.

Ok, I will keep that in mind unless someone else comes before.