Closed Bug 1657850 Opened 7 months ago Closed 6 months ago

Add a pref to control how many background threads are used


(Core :: JavaScript: GC, task)




81 Branch
Tracking Status
firefox81 --- disabled
firefox82 --- fixed


(Reporter: jonco, Assigned: jonco)




(2 files)

The GC uses background threads to parallelise work where possible. How many threads to use is an open question however. In general, using more threads helps but this is limited by memory bandwidth, resource contention and other CPU activity. Even when more threads do give an improvement there are likely to be diminishing returns, while potentially negatively affecting other parts of the system.

Currently we use a maximum of half as many threads as there are CPU cores.

We should add a pref to allow us to experiment with changing this ratio.

This adds a thread count for GC parallel tasks calculated from GC parameters
for a helper thread ratio and max helper thread count. It also adds one to
report the number of helper threads used for GC.

This is slightly complicated by the fact that the helper thread system is
per-process and there are potentially many JS runtimes in a process. I
disallowed setting these parameters from workers (i.e. child JS runtimes), but
there may be more than one non-worker JS runtime so this isn't perfect.

I had to swap the mutex order for the GC and helper thread locks. Whatever
reason they were the other way round seems to have gone and this order makes
more sense to me (I see the GC lock as being 'coarser' than the helper thread

Assignee: nobody → jcoppeard
Pushed by
Add prefs to control how many background threads are used for GC r=sfink
Backout by
Backed out changeset fb664f6d43ed for failures on helper-thread-params.js. CLOSED TREE

Backed out for failures on helper-thread-params.js



failure log:

[task 2020-08-13T18:18:28.711Z] 18:18:28 INFO - TEST-PASS | tests/jit-test/jit-test/tests/gc/gczeal-range.js | Success (code 0, args "--blinterp-eager") [0.1 s]
[task 2020-08-13T18:18:28.729Z] 18:18:28 INFO - Exit code: -11
[task 2020-08-13T18:18:28.730Z] 18:18:28 INFO - FAIL - gc/helper-thread-params.js
[task 2020-08-13T18:18:28.730Z] 18:18:28 WARNING - TEST-UNEXPECTED-FAIL | tests/jit-test/jit-test/tests/gc/helper-thread-params.js | Unknown (code -11, args "") [0.1 s]
[task 2020-08-13T18:18:28.730Z] 18:18:28 INFO - INFO exit-status : -11
[task 2020-08-13T18:18:28.730Z] 18:18:28 INFO - INFO timed-out : False
[task 2020-08-13T18:18:28.734Z] 18:18:28 INFO - Exit code: -11
[task 2020-08-13T18:18:28.738Z] 18:18:28 INFO - FAIL - gc/helper-thread-params.js

Flags: needinfo?(jcoppeard)

Currently we hack around the protected data checks during helper thread
initialization in GlobalHelperThreadState::ensureContextListForThreadCount.
This removes the need to do that and allows us to simplify that method. I added
some more assertions in JSContext::set/clearHelperThread too.

Pushed by
Add an uninitialized JSContext kind to simplify protected data checks r=jandem
Add prefs to control how many background threads are used for GC r=sfink
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
Flags: needinfo?(jcoppeard)
Regressions: 1660346
You need to log in before you can comment on or make changes to this bug.