Open Bug 1914491 Opened 5 months ago Updated 8 days ago

Investigate moving Ion linking off-thread

Categories

(Core :: JavaScript Engine: JIT, task, P1)

task

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.

Whiteboard: [sm-perf-next] → [js-perf-next]

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.

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.)

See Also: → 1490849
You need to log in before you can comment on or make changes to this bug.