1569799 - Divert offthread IonCompile tasks to use the XPCOM helper thread pool

Status: RESOLVED DUPLICATE of bug 1713335

(Core :: JavaScript Engine, enhancement, P2)

Description

[Kris Wright :KrisWright]

We would like to divert the offthread Ion compile work to use the XPCOM thread pool, while retaining native behavior when running the standalone JS shell. To do this, we've registered HelperThreadTaskCallback to pass any RunnableTask* to the task handler [1].

From my understanding, we will need to:

1. Check for the callback in StartOffThreadIonCompile(...) [2] and if the callback exists, call HelperThreadTaskCallback(builder).

2. Ensure that IonBuilder runs its entire parallel job independently of HelperThread. This particularly pertains to sorting itself into the IonFinishedList and pinging the main thread after a job is finished [3]. This may require adding some kind of finish behavior to the RunnableTask interface (such as RunnableTask::onThreadFinish()), or moving these jobs so that they're handled inside IonBuilder::runTask().

Since IonBuilders then get placed into the IonFinishedList, the tasks shouldn't have to worry about being self-destroying. However, if that were to change for any reason, note that IonBuilder will have to destroy itself as HelperThreadTaskHandler only forgets its task pointer and never attempts to destroy it.

[1] https://searchfox.org/mozilla-central/rev/1eb05019f47069172ba81a6c108a584a409a24ea/js/src/vm/Runtime.cpp#75
[2] https://searchfox.org/mozilla-central/rev/1eb05019f47069172ba81a6c108a584a409a24ea/js/src/vm/HelperThreads.cpp#194
[3] https://searchfox.org/mozilla-central/rev/1eb05019f47069172ba81a6c108a584a409a24ea/js/src/vm/HelperThreads.cpp#2132

Comment 1

[Nicolas B. Pierron [:nbp]]

IonMonkey's compilation is divided in 2 parts, the frontend (IonBuilder) and the backend (CompileBackend). Today only the backend is being compiled off-thread and the front-end remains on the main thread.

The problem we are facing with IonBuilder, is that we are manipulating data which can be mutated by the execution, such as JSString, JSObject (template objects), type information, Baseline caches, … Taking a snapshot of all these information would be even more work.

IonBuilder is attempting to do multiple things, the first thing is to transliterate the opcodes into MIR instructions, then specialize these with type information and baseline information, and use this information for inlining more code through an embedded IonBuilder. At this stage, this is a design issue, and would involve a lot of work to divided between the work which can be done without runtime info, and the one which cannot.

I would suggest to first look at IonBuilder optimizations such as optimizing ResumePoint generation (Bug 1454586), or moving the branch pruning phase before IonBuilder (Bug 1396822) to reduce the quantity of memory manipulated instead of moving it off-thread.

Comment 2

[Iain Ireland [:iain]]

Note: this is just a case of crossed wires. Kris is not moving anything offthread that wasn't already there; she's just moving offthread Ion compilation to a new pool. I assume the confusion is because StartOffthreadIonCompile takes an IonBuilder as input, and if you're not already familiar with the code it is reasonable to assume that "IonBuilder" is the name of the compilation task.

Kris: As Nicolas says above, there are two stages to Ion compilation: the IonBuilder stage, which collects all the information necessary to compile, and a second stage which actually does the compilation. You're moving the latter to XPCOM, not the former, so it would be better to call these IonCompile tasks, not IonBuilder tasks.

Comment 3

[Kris Wright :KrisWright]

(In reply to Iain Ireland [:iain] from comment #2)

Note: this is just a case of crossed wires. Kris is not moving anything offthread that wasn't already there; she's just moving offthread Ion compilation to a new pool. I assume the confusion is because StartOffthreadIonCompile takes an IonBuilder as input, and if you're not already familiar with the code it is reasonable to assume that "IonBuilder" is the name of the compilation task.

Kris: As Nicolas says above, there are two stages to Ion compilation: the IonBuilder stage, which collects all the information necessary to compile, and a second stage which actually does the compilation. You're moving the latter to XPCOM, not the former, so it would be better to call these IonCompile tasks, not IonBuilder tasks.

Thanks for the clarification! I changed the bug summary to better reflect what we're doing.

This change (moving offthread work to XPCOM thread pools) isn't meant to change the fundamental behavior of that offthread work. An interesting fact about the IonBuilders is that they're the only type being passed to a StartOffThread* function that isn't specifically used for offthread jobs, so my understanding of how they work is a bit fuzzy.

Comment 4

[Jon Coppeard (:jonco)]

The current plan is to switch over from using the internal pool to the external pool in one go, so I'm closing the bugs for individual task kinds.