In a browser session that I've used for a couple days (6 days old nightly build: 79.0a1 (2020-06-10) (64 bits)), I have a content process that continuously uses 40+% of a CPU core.

about:processes shows that this content process has 183 threads (other content processes have 40 to 50 threads).

In the list of threads for this content process, I see 40+ PacerThread threads (each taking about 0.5% of a CPU core), 40+ VoiceProcessThread threads (each taking about 0.4% of a CPU core), and about as many ModuleProcessThread threads (each taking about 0.1% of a CPU core). There's also an SCTP timer thread that seems related to webrtc, taking about 0.1% of a core.

I don't have steps to reproduce for this, but I think it's likely related to using https://virtu-allhands.com (28 sessions to this site shown in about:webrtc).

I somehow can't seem to capture a profile of these threads, are they somehow not registered with the Gecko Profiler?

Thanks for the report! PacerThread, VoiceProcessThread and ModuleProcessThread are created in libwebrtc. PacerThread and ModuleProcessThread are associated with the Call object, VoiceProcessThread with the voice engine. These would be owned by the VideoConduit or AudioConduit which are in turn owned by a Transceiver. So this would suggest you've ended up with 40+ Transceivers that are either staying around or have gone away but not cleaned up properly.

Byron, any thoughts on whether this could be a site issue or if it indicates a bug in our code?

If the tabs are closed, then this stuff should not be hanging around.

The SCTP timer stuff probably only goes away when the sctp_stack is shut down, but we only do that at xpcom shutdown time due to bug 1646716.

The timer threads wakes up periodically and serves timers when needed. That seems OK to me. Of course one could implement them in a different way to sleep until the next timer runs off, but that is not how it is done today.