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: enable 2 content processes on nightly (target: Firefox 52, tracking: M1)

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
  • Session storage is not designed for multiple content processes, next generation DOM storage will fix this problem: bug 1286798
  • Some test will need some refactoring: bug 1301015 but for now we will force them to use single content process: bug 1301340

M2: preparation for scaling (3 months)

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

M3: scaling (ongoing)

• Currently vaguely defined, but the main focus will be memory optimization and the goal is to enable more content processes.

Meetings

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

Core Development Areas

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.

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

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.
• Out of process WE add-ons is not part of the project
• Some add-ons might break because of false assumptions (JSM has to be loaded per process now for example)

Testing

• Existing tests should work with 2 content processes.
• Areas where additional testing is needed have to be identified.

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

• M1 [e10s-multi:M1] in whiteboard
• M2 [e10s-multi:M2] in whiteboard
• Triage[e10s-multi:?] in whiteboard
• ServiceWorkers meta owners: Ben Kelly, Andrew Sutherland
• LocalStorage refactoring owner: Jan Varga

Links

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