Ted Campbell [:tcampbell] Reporter
	Description • 6 years ago

The nursery is currently a large contributor to content process overhead. It is currently a fixed 1MB allocation that does not go away. On the other hand, the nursery is an important part of browser performance.

Heuristics for dynamically resizing the nursery are hard to get right, but we can instead use the notion of background/throttled tabs. This should be a little more predictable and prioritize foreground tabs.

In Bug 1433007, :pbone has been observing that reducing the nursery size to ~160kB still leaves something functional. This is probably a good starting goal for off-thread. The GC supports disabling the nursery entirely, but that may have weirder perf side-effects than we can tolerate.

In Bug 1468099, the TabGroup::HasOnlyThrottableTabs() API was added which might be a good starting point. Another point may be nsJSEnvironmentObserver::Observe() if we need an observer event. We can discuss with dom / front-end about how to fire this event.

	Steve Fink [:sfink] [:s:]
	Comment 1 • 6 years ago

(from jesup on IRC)

Background tabs can have (significant) JS running, like webrtc, webaudio, video (audio) playback, etc. And background has two variants: non-focused-but-visible (i.e. another window), and non-visible. We have to care about such aspects for things like timer request throttling already, so we could key off of those decisions. This also can interact with the Page Lifecycle API proposal (which includes freezing or unloading background tabs to the existing cycle). I'd presume non-visible is the focus. [jonco agreed]

	Ted Campbell [:tcampbell] Reporter
	Comment 2 • 6 years ago

The |HasOnlyThrottableTabs| API should be covering those much of that: https://searchfox.org/mozilla-central/source/dom/base/TimeoutManager.cpp#1088-1092