Open Bug 1475091 Opened 4 years ago Updated 3 years ago

Dropping rayon thread pool when a content process is inactive?

Categories

(Core :: CSS Parsing and Computation, enhancement, P3)

enhancement

Tracking

()

Tracking Status
firefox63 --- affected

People

(Reporter: xidorn, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [overhead:250K])

We spawn several style threads (min(6, max(1, no. of cores * 3 / 4))) for each process, and each of the thread has 256KB stack,

Maybe we can drop those threads and release their stack when a content process becomes inactive, and recreate the pool in tab switching (maybe tab warming would help)?
Priority: -- → P3
Yeah, this seems like a good idea. Most of the time these stacks don't get deep, except occasionally during invalidation handling, and also stuff like bug 1395708#c15. Dynamically deactivating the thread pool is probably smart.
TabGroup::HasOnlyThrottableTabs may or may not be useful here.
There should probably be some notification telling when process is totally in background or not.
At a minimum we're looking at 25K per thread, assuming 6 threads that's 150K. Bug 1395708, comment 15 saw something more like 100K of committed stack space, so that' would give us 600K. For an optimistic guess I'm putting this in the 500K range.
Whiteboard: [overhead:500K]
(In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment #4)
> At a minimum we're looking at 25K per thread, assuming 6 threads that's
> 150K. Bug 1395708, comment 15 saw something more like 100K of committed
> stack space, so that' would give us 600K. For an optimistic guess I'm
> putting this in the 500K range.

That bug was specifically about an infrequently-used Cocoa color API that allocated an enormous amount of stack space, so I'm skeptical that we end up committing that much in practice, especially on average. I think 250k is probably a more likely estimate.
(In reply to Bobby Holley (:bholley) from comment #5)
> That bug was specifically about an infrequently-used Cocoa color API that
> allocated an enormous amount of stack space, so I'm skeptical that we end up
> committing that much in practice, especially on average. I think 250k is
> probably a more likely estimate.

Makes sense, updated.
Whiteboard: [overhead:500K] → [overhead:250K]
Blocks: 1476432
One thing we need to note here is that we currently can't destroy per-thread arenas (bug 1364359), so we'd need to do something to hang onto a reference and reuse the existing ones.
You need to log in before you can comment on or make changes to this bug.