Multiple content processes: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(nit)
(moving under electrolysis)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== 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 ==
There are many strategies to choose from. The (practically) unlimited process count is on some platforms not a realistic goal, and having a separate process for each open site instances or even sites does not seem like a reachable goal (for now at least). Which means using content processes as a security membrane cannot be a goal either. With limited process count probably content-process crash or hangs will still affect other tabs as well, but at least not all of them. We should find a way to crash content processes gracefully as much as it's possible.
== Memory management ==
[http://www.erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/ Memory cost of a content process] Seems to be relatively high right now.
[http://www.erahm.org/2016/02/12/are-they-slim-yet/ Memory usage of e10s compared to other browsers] gives us some breathing space.
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/ Nuva] which is based on copy-on-write forking mechanism that is provided by Linux. Unfortunately it is not really feasible on Windows.
Another approach was suggested by Till Schneidereit [https://bugzilla.mozilla.org/show_bug.cgi?id=876173 lazy cross-process memory sharing].
We also want to monitor the resource usage of each subprocess {{Bug|1255843}} which will open doors for further optimization strategies.
== Process strategy ==
Google already did the research in 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}}.
== Performance ==
Current Talos tests gives very little information about the difference between one and multiple content processes. We need more tests.
*Some talos tests should use multiple tabs simultanously (if they don't already):
** sessionrestore / sessionrestore_no_auto_restore
** tps
** tresize
** tart
*Some talos tests are not very usefull for this comparison:
** ts_pain
** tsvgx
** tsvg-opacity
** dromeo
** a11y
** tscrollx
** tresize
*Finally we should introduce new tests that reflects our goals
== Bug tracking ==
* Main tracking bug: {{bug|1207306}}
* [https://docs.google.com/document/d/1BgyP6kc20qKUjg77iAfhRSb7lVMvSIKMRWh277JzcVM/edit  Initial bug prioritrisation]
== Add-ons status ==
It is yet to be investigated. WEAPI related tests seems to be broken with the multiple content processes and SDK based add-ons probably come with a big memory overhead per process.
== Roadmap plan ==
To be decided.

Latest revision as of 14:19, 23 March 2016

Retrieved from "https://wiki.mozilla.org/index.php?title=Multiple_content_processes&oldid=1123701"