Open Bug 1501438 Opened 6 years ago Updated 1 year ago

[meta] Use XPCOM thread pools for Spidermonkey

Categories

(Core :: JavaScript Engine, enhancement, P2)

enhancement

Tracking

()

People

(Reporter: tcampbell, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Keywords: meta)

Long term, it makes sense to migrate our JS off-thread tasks to use the XPCOM thread pool. This allows us to get features like idle-thread shutdown and in the future a better global scheduling story. Threads are a big source of content memory overhead currently and SpiderMonkey needs to reduce it's contribution to the problem.

The XPCOM thread pool stuff is unlikely to every migrate into MFBT, so standalone spidermonkey will need to continue to have a naive thread pool available. I don't feel this is a strong issue since much of our use of threads is straightforward.

The approach would be to refactor our use of background threads to have a simple API, and then begin mapping it to XPCOM thread pools.

First step is to enumerate the uses of background threads we currently have (in this bug), and determine what constraints we have (scheduling, thread count, etc).

(CC-ing a bunch of people since this is a cross-cutting issue. I believe I've spoken to most of you already.)
Note we also have bug 1499538 on file which proposes adding just a few basic features of xpcom thread pools (mainly spinning down idle threads to reclaim stacks). This is a larger project that we weren't sure if we'd get buy-in from the JS side, but it sounds like y'all are on board so it might make sense to focus efforts here.
Blocks: 1499538
Depends on: 1502459
Summary: Use XPCOM thread pools for Spidermonkey → [meta] Use XPCOM thread pools for Spidermonkey
Depends on: 1512324

We discussed this with KrisWright this afternoon. The plan is to start by sending low priority tasks to the XPCOM thread pool, and progressively migrate the other tasks. This would have to be configurable behind a pref, although that would be dealt with on the XPCOM side. We would have to keep the current task scheduling mechanism for the time being because the XPCOM thread pool doesn't support priorities yet. If we can make this work effectively then we would cut over. We would also need a simple thread pool in the JS shell at that point.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.