1832368 - Put all XPCOM threads in the background in background browsing contexts

Status: NEW

(Core :: XPCOM, enhancement)

Description

[Kris Wright :KrisWright]

In bug 1805932 we put the main thread in the background. This bug tracks the process of putting other XPCOM threads in the background as well. This process will undoubtedly be a lot more complicated, as we need to go through our nsThread infrastructure to make threads and thread pools aware of their status in the background without causing spurious wakeups, and likewise when reentering the foreground. This runs the potential of giving us additional power savings on Apple Silicon.

Comment 1

[Kris Wright :KrisWright]

Attachment: WIP: Bug 1832368 - Implement background behavior for all nsThreads.

This part is especially tricky and what exists here so far is what I am using to test the behavior. Notifying the threads that they need to go into the background is where the main hangup is - preventing spurious wakeups while also noticing the change. To solve this I am dealing with a global background value which threads can check during dispatch. If they notice there has been a measurable change, they can dispatch to their own event target first a method to set themselves into the background. I haven't worked out yet how we'll be notifying the mechanism of the changes.

Comment 2

[Florian Quèze [:florian]]

Here is a power profile I captured yesterday: https://share.firefox.dev/3wqlKyj
The content process is in the background priority. Despite a lot of CPU activity in the main thread (long GC), the power use of the process is limited (the power is < 200mW most of the time), however, the power use increases dramatically as soon as there's some activity in the DOM Worker thread, using more than 3W.

Kris, what's the current plan to fix this bug? If getting a solution that works for all threads is tricky, would it make sense to address first the DOM Worker threads (ie. the threads the web page can control)?

Comment 3

[Kris Wright :KrisWright]

Currently no decision has been made about offthread work in background tabs - we may be able to investigate lowering the priority of particular threads for heuristic improvements. Currently I haven't been doing any work on this - the main thread experiment is ongoing ATM.