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 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
- 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
- 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 addition 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 |
ts_pain tsvgx |
Running active web content
simultaneously in multiple tabs |
Bug tracking
Links
- Process Model (2012)
- Recent dev.platform discussion