1435997 - [meta] Turn the helper threads system into a real scheduler

Status: NEW

(Core :: JavaScript Engine, enhancement, P3)

Description

[Lars T Hansen [:lth]]

The helper thread system is weak in a number of ways: it is implemented inefficiently, it has a completely static (== starvation-prone) priority system with hacks to work around the worst cases, it does not use robust mechanisms to detect the platform configuration, it does not express dependencies but has hacks to deal with that when necessary, it has plenty of duplicated code, it has an amorphous API with ad-hoc call-ins to "fix" problems that make it hard to maintain and hard to predict its behavior.  It also does not interact with Firefox, which also has a lot of active threads.

Yet we increasingly rely critically on threads in the JS engine for performance of compilation and GC.

This bug serves as the metabug to collect these issues, lest they be lost.  Whether we should fix the worst corner cases and live with the rest, or rewrite the scheduler in some disciplined way to be a real scheduler, is an interesting point for debate.  Discuss.

Comment 1

[Luke Wagner [:luke]]

Another general point brought up earlier in in-person discussions: we may actually have enough parallelism, especially during page load (say, wasm + stylo), that it would be beneficial to not have N different thread pools, each assuming they have num-cpus available to them.  Thus, if we build something more principled here, it might make sense to do it in MFBT and get other places in Gecko to use it.