Electrolysis/Multiple content processes: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(bold for milestones)
(post London update)
Line 24: Line 24:
* [http://www.erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/ Memory cost of a content process] - relatively high
* [http://www.erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/ Memory cost of a content process] - relatively high
* [http://www.erahm.org/2016/02/12/are-they-slim-yet/ Memory usage of e10s compared to other browsers] - we're not the worst offender
* [http://www.erahm.org/2016/02/12/are-they-slim-yet/ Memory usage of e10s compared to other browsers] - we're not the worst offender
==== NUWA ====
The challenge is to avoid the content processes allocating memory for the same resources. B2G is already using multiple content processes for apps, and solving this problem with [https://blog.mozilla.org/nnethercote/2014/02/11/nuwa-has-landed/ Nuwa] which is based on copy-on-write forking mechanism that is provided by Linux. [https://msdn.microsoft.com/en-us/library/windows/desktop/aa366551(v=vs.85).aspx Windows have a quite different API to share memory between processes] and it has to be investigated if it's usable for Nuwa. [https://msdn.microsoft.com/en-us/library/windows/desktop/aa366551(v=vs.85).aspx Boost] uses this API for memory sharing.


==== Lazy Sharing ====
==== Lazy Sharing ====
Another approach was suggested by Till Schneidereit [https://bugzilla.mozilla.org/show_bug.cgi?id=876173 lazy cross-process memory sharing].
Extending Nuwa for all platform does not seem realistic, and since the most memory overhead comes from JS, we should address the problem at JS engine level first. Till Schneidereit suggested [https://bugzilla.mozilla.org/show_bug.cgi?id=876173 lazy cross-process memory sharing].
We also want to monitor the resource usage of each sub-process {{Bug|1255843}} which will open doors for further optimization strategies.
 
=== Process Allocation ===
Google researched this area and came up with various [https://www.chromium.org/developers/design-documents/process-models models]. Process per tab is what describes the best what we have right now in Gecko with a cap on the process count. I don't see a strong reason to try to use any other models until we fix the scaling problem (and it is not guaranteed that the problem can be fixed).
 
A nice addition would be to the platform to let tabs switch processes, or maybe even to move inactive tabs content entirely to another process to give us more space for run-time optimizations {{Bug|1251966}}.
 
One thing we have to ensure is that connected windows stay always in the same process {{Bug|1251964}}.


=== Other Problem Areas ===
=== Other Problem Areas ===
Areas of the browser which may be incompatible in some way with multiple content processes.
Areas of the browser which may be incompatible in some way with multiple content processes.


* Shared workers
* Service workers
* Session storage
* Plugins
* Plugins
* Dev Tools / Browser Content Toolbox
* Browser Content Toolbox (this should be fixed on the back-end already)
* Printing
* Printing
* Crashed tab handling, crashed tab page
* Crashed tab handling, crashed tab page
* Crash reporting
* Crash reporting
* Some Add-on breakage


== Add-ons ==
== Add-ons ==

Revision as of 13:38, 21 June 2016

Goals

After e10s is enabled for all users, the next step is to introduce multiple content processes. The goal is to bring out the most from the multi process architecture we introduced with e10s, gain performance where it's possible and minimize the impact of content process crashes. The challenge is to achieve this without scarifying our advantage we currently have in memory usage compared to our competitions.

What to expect

First we want to enable 2 content processes then after some optimization increase that number to a reasonable cap. Once we have that we can think about advanced process models, sandboxing and how can we get the most out of multiple content processes.

Roadmap

M1: general correctness ([e10s-multi:M1] in whiteboard)

  • Fix correctness bugs (making 2 processes correct).
  • Ignore memory footprint.
  • Create framework for tab<->process selection code.
  • service/shared workers in their own process.

M2: preparation for scaling

  • Measure the memory footprint of content processes.
  • Start optimizing memory use.
  • Strategy to go beyond 2 content processes (aiming for 5 initially).

M3: scaling (currently vaguely defined, but the main focus will be memory optimization and the goal is to enable more content processes)

Core Development Areas

Memory management

Lazy Sharing

Extending Nuwa for all platform does not seem realistic, and since the most memory overhead comes from JS, we should address the problem at JS engine level first. Till Schneidereit suggested lazy cross-process memory sharing.

Other Problem Areas

Areas of the browser which may be incompatible in some way with multiple content processes.

  • Shared workers
  • Service workers
  • Session storage
  • Plugins
  • Browser Content Toolbox (this should be fixed on the back-end already)
  • Printing
  • Crashed tab handling, crashed tab page
  • Crash reporting
  • Some Add-on breakage

Add-ons

  • Web extension testing seems to be broken with the multiple content processes
  • SDK based add-ons probably come with a big memory overhead per process.
  • Running WE add-ons in separate processes?
  • Do e10sified legacy add-ons work?
  • Do shimmed legacy add-ons work?

Testing

TBD

Performance Testing

Current Talos tests gives very little information about the difference between one and multiple content processes. We need more tests.

Some tests should use

multiple tabs simultaneously

Others are irrelevant Additional test we need
sessionrestore

sessionrestore_no_auto_restore
tps
tresize
tart

ts_pain

tsvgx
tsvg-opacity
dromeo
a11y
tscrollx
tresize

Running active web content

simultaneously in multiple tabs

Bug tracking

Links