1499538 - Reduce the overhead of JS helper threads

Status: NEW

(Core :: JavaScript Engine, enhancement, P2)

Description

[Eric Rahm [:erahm]]

JS helper threads [1] contribute a significant amount to per process overhead (see bug 1476442) and we'd like to reduce that. There are several options ranging from simply reducing the max amount of threads [2] to cycling down threads and respawning as needed in order free up committed stack space (nsIThreadPool [3] already has this logic).

It would be useful to run some tests against awfy / talos to see what effect reducing the threadcount has. Additionally gathering some data on thread utilization would be helpful as well.

[1] https://searchfox.org/mozilla-central/rev/3d989d097fa35afe19e814c6d5bc2f2bf10867e1/js/src/vm/HelperThreads.h#106
[2] https://searchfox.org/mozilla-central/rev/3d989d097fa35afe19e814c6d5bc2f2bf10867e1/js/src/vm/HelperThreads.cpp#86-104
[3] https://searchfox.org/mozilla-central/rev/3d989d097fa35afe19e814c6d5bc2f2bf10867e1/xpcom/threads/nsIThreadPool.idl#49-58

Comment 1

[Eric Rahm [:erahm]]

Kris, can you take a look at this?

Comment 2

[Jon Coppeard (:jonco)]

When I tested using these threads for GC work and for parsing I found very little gain when using more that half the threads, so I think there is scope for reduction.  The optimum number of threads probably depends on more factors than the reported number of CPUs though.

Comment 3

[Lars T Hansen [:lth]]

For wasm compilation, which is massively parallel, we do see improvements as we add cores until we hit a NUMA limit, at which point performance drops again.  So a fair amount of benchmarking that we did for the baseline compiler was done with careful control of CPU affinity.  Anyone testing should probably be mindful of this.  95% of our desktop use base has <= 4 cores anyhow, based on the data report (https://data.firefox.com/dashboard/hardware), and it's a fair bet that almost none of them have NUMA systems.

Comment 4

[Luke Wagner [:luke]]

Agreed; we definitely see benefits up to 8, but adding logic to dynamically ramp up/down the number of helper threads based on activity makes sense.