Open Bug 1685016 Opened 3 years ago Updated 3 years ago

Avoid running GCs on background tabs while foreground tabs are loading a page

Categories

(Core :: DOM: Content Processes, enhancement, P3)

Product:
Core
Component:
DOM: Content Processes
Type:
enhancement

Tracking

()

Status:
ASSIGNED

People

(Reporter: pbone, Assigned: pbone)

References

Details

An extension to Bug 1629064 but I want to land it separately.

Avoid starting a GC for a process in the background if a foreground process is doing a "prioritised operation" such as pageload.

Randell warns that we should be careful to not block GCs forever for pages that are very slow to load.

Severity: -- → N/A
Priority: -- → P3

An upper bound on the possible improvements here would be to totally disable GC (during load of any tab), and see what impact it has.

So there's a few things to clarify.

  • Once Bug 1629064 lands then this change is a one-line-change. It'll be very easy to implement and test.
  • This won't prevent all GCs, eg GCs triggered because of allocation threasholds will continue normally (but I'd like to have a conversation about them at some point and adjust their tuning depending on a tab's status). The GCs it should stop are those that are fired from PokeGC which is used to do things like compacting GCs if the user is idle, or PAGE_HIDE GCs if a tab is closed.
  • The "is loading" state we can use is the sChildProcessesRunningPrioritisedOperation flag in https://searchfox.org/mozilla-central/source/ipc/glue/IdleSchedulerParent.cpp#196-202 which seems to be set when we're loading a top-level document https://searchfox.org/mozilla-central/source/dom/base/Document.cpp#17066-17084. I don't know if that's a suitable status to use, it's just the one already available in the idle scheduler.
  • We're discussing modifying Bug 1629064 to avoid starvation anyway.

Today Randell also mentioned that if the network is slow there may still be plenty of CPU cycles avalable to run GCs, and delaying GCs may be a bad idea for plenty of other reasons. We're quickly getting into the huge gray area of "tuning" and I have no easy answers. Even something like measuring the load average and making decisions based on that wouldn't work if the user is compling Firefox or mining bitcoins. At best we can probably just change the number of processes that we'll let run a background GC, I'd almost say to "keep it above 1" but I'd like to start making decisions based on the type of GC. Eg say no to compacting GCs done because a process is idle (the user hasn't interacted with that process) but yes to PAGE_HIDE GCs. And always allow at least one memory pressure GC.

You need to log in before you can comment on or make changes to this bug.