1305091 - Stop using content processes when they are using "too much" memory

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect)

Description

[Benjamin Smedberg]

When a content process starts using "too much" memory, it's much more likely to crash. Depending on why we're using memory, this can also correlate with high GC/CC pause times or other general jank.

So something I think we should do short-term is stop assigning new tabs to an existing content process when it has high memory. We'll call this a "deprecated content process".

More complex (move to another bug/later?) would be to move *existing* tabs to another process on page navigation.

Proposed criteria for marking a content process as deprecated:
* on any system (32-bit/64-bit) >1G private bytes
* on any system: more than one GC pause >500ms in the last hour
* on 32-bit systems: <512M largest available block of VM

Comment 1

[Benjamin Smedberg]

Attachment: Bug 1305091 - Stop using content processes when they are running out of memory data-r?francois

Review commit: https://reviewboard.mozilla.org/r/110398/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/110398/

Comment 2

[Robin Steuber (she/her) [:bytesized]]

Comment on attachment 8834463 [details]
Bug 1305091 - Stop using content processes when they are running out of memory data-r?francois

https://reviewboard.mozilla.org/r/110398/#review111696

This looks good to me.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 8834463 [details]
Bug 1305091 - Stop using content processes when they are running out of memory data-r?francois

https://reviewboard.mozilla.org/r/110398/#review111820

Comment 4

[François Marier [:francois]]

Comment on attachment 8834463 [details]
Bug 1305091 - Stop using content processes when they are running out of memory data-r?francois

https://reviewboard.mozilla.org/r/110398/#review111876

datareview+

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/63af206d8770
Stop using content processes when they are running out of memory, r=mrbkap+ksteuber data-r=francois

Comment 6

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/63af206d8770

Comment 7

[Gabor Krizsanits (INACTIVE)]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #0)
> More complex (move to another bug/later?) would be to move *existing* tabs
> to another process on page navigation.

I talked to Bill about this a while ago and the only realistic way to move tabs/windows between processes currently, would be to reload them (using session store, restore tab probably). Which could be done easily for background tabs, especially since there is also a plan to unload some of the background tabs in some cases. On the plus side that would not be terrible difficult to implement.

> 
> Proposed criteria for marking a content process as deprecated:
> * on any system (32-bit/64-bit) >1G private bytes
> * on any system: more than one GC pause >500ms in the last hour
> * on 32-bit systems: <512M largest available block of VM

I guess we will block this functionality on e10s-multi, because of service workers mainly, or do you plan to release it sooner? Do you plan to add a cap for the number of concurrent deprecated processes?

Comment 8

[Benjamin Smedberg]

My current plan was to let this ride the trains now not blocking on e10s-multi, and monitor how frequently it happens. If it happens a lot to certain users (more than 4x/session)s, we may need to implement capping, but right now I doubt that will be a problem.