Open
Bug 1501438
Opened 6 years ago
Updated 2 years ago
[meta] Use XPCOM thread pools for Spidermonkey
Categories
(Core :: JavaScript Engine, enhancement, P2)
Core
JavaScript Engine
Tracking
()
NEW
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.)
Comment 1•6 years ago
|
||
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.
Updated•6 years ago
|
Summary: Use XPCOM thread pools for Spidermonkey → [meta] Use XPCOM thread pools for Spidermonkey
Comment 2•5 years ago
|
||
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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•