Open Bug 1501438 Opened 2 years ago Updated 11 months ago
[meta] Use XPCOM thread pools for Spidermonkey
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.
Summary: Use XPCOM thread pools for Spidermonkey → [meta] Use XPCOM thread pools for Spidermonkey
You need to log in before you can comment on or make changes to this bug.