Electrolysis/Multiple content processes

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 sacrificing the advantage we currently have in memory usage compared to our competitors.

One explicit non-goal of this project is to nest content processes for e.g. iframes. There is work underway to do that in bug 1277066 in parallel to this project.

What to expect

First, we will enable 2 content processes and fix correctness bugs in the DOM and frontend components. Then we will start ramping up the number of content processes while optimizing memory use in order to avoid using too much memory overall. 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[Nightly bug 1303113]: enable 2 content processes on nightly (Done)

Apart a few corner cases 2 content processes are fairly stable for everyday usage. Our hope is that by enabling 2 content processes on nightly despite a few known issues that will be time consuming to fix (session storage / shared workers) we will get better bug reports early.

• Ignore memory footprint.
• Fix crash report in background tabs bug 1241459
• Known issues that will block riding the train but will not block enabling 2 content processes on nightly:
  • Service/Shared workers should run in their own process: bug 1231208
  • Some test will need some refactoring: bug 1301015 but for now we will force them to use single content process: bug 1301340

M2[Aurora bug 1304546]: Correctness, Measuring Performance and Memory, and Scaling to 4 Processes (Done)

• Measure the memory footprint of content processes
• Measure startup of content process (bug 1336389, bug 1304790)
• Start optimizing memory use
• Prepare to go beyond 2 content processes (aiming for 4 initially bug 1336398).
• Service Workers in it's own content process <== we are not going to block on a full implementation of this.
• AWSY (bug 1272113)

M3[Beta bug 1304547]: Optimization and Preparing for Release

• Memory optimization
• Performance optimization
• Solidifying Automated tests (working with module owners)
• General Convergence; focusing on quality

Release Criteria

• Crash Rates need to be low enough that they have little, if any perceivable impact to the overall crash rates. See the crash rates starting with Firefox 54 Beta, here.
• Memory Total
• Tab Switch Spinners
• We may need to activate e10s-multi based on physical RAM size depending how the number of content processes impacts such memory. We have a hypothesis for both cases (increased number of content process will either benefit systems with lower RAM or make things worse).

Release Plan

• e10s-multi is currently enabled with 4 processes in Firefox 55 Nightly
• We plan on uplifting as many changes as possible to Firefox 54 Aurora and enabling 4 processes
• If everything looks good, we will conduct an experiment in Beta 1

Memory management

• Memory cost of a content process - relatively high
• Memory usage of e10s compared to other browsers - we're not the worst offender
• 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.

Testing

• Currently for bc/dt tests we keep content processes alive to fight timeouts
• Areas where additional testing is needed have to be identified.
• Some tests were disabled, re-enabling them is high priority work currently

Process startup time

• Improve content process startup time

Bug tracking

• Triage[e10s-multi:?] in whiteboard

Links

• Process Model (2012)
• Recent dev.platform discussion

Meetings

We are meeting every week at 9am PDT (6pm CEST) starting on June 28.