1476432 - [meta] Reduce thread overhead

Status: NEW

(Core :: XPCOM, enhancement)

Description

[Eric Rahm [:erahm]]

The amount of threads we spin up can have a large impact on per process memory overhead. For example on 64-bit Windows we know there's a guaranteed 24K overhead per thread not including committed stack space.

We need to identify what threads we currently have, where they come from, how much committed stack space they use, and what we can do to reduce the overall amount of threads.

Several options present themselves:

1) Provide a general purpose thread pool that can be shared rather than spinning up ad-hoc thread pools
2) Provide a standard low-priority thread for processing one-off events off main thread (the stream transport thread is often used for this)
3) Make existing threads lazily instantiate themselves
4) Add heuristics to our thread pool to spin down threads that have large committed stacks

Comment 1

[Nathan Froyd [:froydnj]]

Bug 1450059 may be relevant here.

Comment 2

[Mike Hommey [:glandium]]

> 1) Provide a general purpose thread pool that can be shared rather than spinning up ad-hoc thread pools

Sadly, rust contributes to the problem. Thankfully, afaict, rayon is the only thread pool used by the rust code we use at the moment.

Comment 3

[Kris Maglione [:kmag]]

(In reply to Mike Hommey [:glandium] from comment #2)
> > 1) Provide a general purpose thread pool that can be shared rather than spinning up ad-hoc thread pools
> 
> Sadly, rust contributes to the problem. Thankfully, afaict, rayon is the
> only thread pool used by the rust code we use at the moment.

Nope. https://searchfox.org/mozilla-central/rev/c296d5b2391c8b37374b118180b64cca66c0aa16/media/audioipc/client/src/context.rs#119-126

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

In bug 1145354 we landed a (local to mtransport) SingletonThreadHolder that does a shutdown-on-unused, though this is gated on a known use-count.  Earlier patches there worked to extend/wrap LazyIdleThread, which has a number of restrictions that make it harder to use for certain usecases (see bug 1145354 comment 5 for a bit on that, such as with IPC).  As discussed there, extending/reworking LazyIdleThread to be less specialized (remove some of the restrictions, perhaps move some bits of it to nsThread in the process) might help a fair bit by making it easier to replace (with minimal caller changes) existing nsThreads with LazyIdleThreads.

Comment 5

[Ryan Hunt [:rhunt]]

I agree that we should combine some of our ad-hoc thread pools and have a global system one.

One to be aware of is the paint worker pool for parallel painting with OMTP [1].

It's sized between 1-4 threads depending on the processor count. I don't believe it has idling behavior to spin down the worker threads. The stacks can also get quite deep on these threads too, as seen in bug 1471892 (which is possibly exceptional).

[1] https://searchfox.org/mozilla-central/rev/8384a6519437f5eefbe522196f9ddf5c8b1d3fb4/gfx/layers/PaintThread.cpp#223

Comment 6

[Kris Maglione [:kmag]]

(In reply to Randell Jesup [:jesup] from comment #4)
> In bug 1145354 we landed a (local to mtransport) SingletonThreadHolder that
> does a shutdown-on-unused, though this is gated on a known use-count. 
> Earlier patches there worked to extend/wrap LazyIdleThread, which has a
> number of restrictions that make it harder to use for certain usecases (see
> bug 1145354 comment 5 for a bit on that, such as with IPC).  As discussed
> there, extending/reworking LazyIdleThread to be less specialized (remove
> some of the restrictions, perhaps move some bits of it to nsThread in the
> process) might help a fair bit by making it easier to replace (with minimal
> caller changes) existing nsThreads with LazyIdleThreads.

There are some other places where this would definitely be useful. The HTML Parser thread comes immediately to mind. I don't think we can use a thread pool for that. But maybe a regular LazyIdleThread would work.

There are also some threads we use for IPC actors that are probably only needed sometimes. The DOM File thread comes immediately to mind there. Although it might make more sense to merge that with the necko Socket Thread.

(In reply to Ryan Hunt [:rhunt] from comment #5)
> It's sized between 1-4 threads depending on the processor count. I don't
> believe it has idling behavior to spin down the worker threads. The stacks
> can also get quite deep on these threads too, as seen in bug 1471892 (which
> is possibly exceptional).

I think you're right. I've seen those 4 threads show up in my content processes and then never go away.

Comment 7

[(no longer active)]

(In reply to Nathan Froyd [:froydnj] from comment #1)
> Bug 1450059 may be relevant here.

Bug 990804 is another old bug on this topic, maybe there is some interesting historical context there too.