Investigate moving Ion linking off-thread
Categories
(Core :: JavaScript Engine: JIT, task, P1)
Tracking
()
People
(Reporter: iain, Unassigned)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [js-perf-next])
After an off-thread Ion compile is complete, there's a linking step that runs on the main thread. See LinkIonScript, which bottoms out in CodeGenerator::link. This shows up in Speedometer profiles.
It would be nice if we didn't have to spend main-thread time on linking. Markus is very keen on eliminating this. It could potentially let us Ion-compile more aggressively. However, linking touches a bunch of data that is currently only available on the main thread.
As a first step, we should audit the Ion linking code to figure out whether there's any low-hanging fruit that we could move off-thread incrementally.
js-perf-next: Investigate ion linking to identify which steps are most expensive. Determine what changes would be necessary to move expensive steps off-thread. Open bugs for any low-hanging fruit.
Reporter | ||
Updated•5 months ago
|
Comment 1•5 months ago
|
||
Please don't do it yet, or make it such that it can be toggled back …
While I agree from the performance point of view, and I want us to go this way in the future. I would prefer if we could have a degraded mode which can be toggle in about:config such that users might still fallback on main-thread linking when there is no-hardware / no-OS support to help mitigate against JIT Spraying attacks.
Not keeping a main-thread linking will prevent us from having an mprotect-based protection based on code-data separation.
Reporter | ||
Comment 2•5 months ago
|
||
It seems very reasonable to make sure that we preserve the ability to do main-thread writing-to-executable-pages. Among other things, we still use mprotect in the parent process, so we need to remain compatible with that.
There are other steps of CodeGenerator::link (random example: generateCompactNativeToBytecodeMap) where I can imagine that it would be less problematic to move it offthread. (Or maybe not, if it depends on knowing the final address of the code. This is very much intended as an exploratory bug.)
Updated•8 days ago
|
Description
•