Make new toplevel sites prefer a new content process, new iframes prefer an existing content process
Categories
(Core :: DOM: Content Processes, enhancement)
Tracking
()
People
(Reporter: cpeterson, Assigned: nika)
References
Details
(Whiteboard: fission-soft-blocker)
Attachments
(1 file)
For new iframes, try to use an existing content process. For new toplevel sites, try to allocate a new content process, unless we have reach the dom.ipc.processCount.webIsolated
limit.
Replace GetNewOrUsedLaunchingBrowserProcess(/* aPreferUsed = */ false)
with GetNewOrUsedLaunchingBrowserProcess(/* aPreferUsed = */ !IsTop())
here:
Comment 1•3 years ago
|
||
What's the reasoning for this out of curiosity?
Reporter | ||
Comment 2•3 years ago
|
||
What's the reasoning for this out of curiosity?
Based on the promising early results from our Nightly experiment comparing dom.ipc.processCount.webIsolated
limit 1 versus 4 processes per site, we'd like to increase dom.ipc.processCount.webIsolated
to something greater than 1. That is bug 1727158.
This bug's proposed change will try to balance the responsiveness benefits versus increased memory usage by preferring to reuse existing content processes for new iframes (assuming they will be lightweight) and use new content processes (until we hit the limit) for toplevel sites in tabs (for improved responsiveness and crash isolation).
Assigning to Nika because, IIRC, she offered last week to write this patch.
Reporter | ||
Comment 3•3 years ago
|
||
Deferring this bug from Fission Milestone M8 to MVP. This bug doesn't need to block our Release channel experiment (M8) and we wouldn't uplift a fix to Beta 92 this late in the beta cycle.
Assignee | ||
Comment 4•3 years ago
|
||
Pushed by nlayzell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7fffdb095dd9 Prefer using existing content processes for subframes during process selection, r=farre
Comment 6•3 years ago
|
||
bugherder |
Description
•