Electrolysis/Multiple content processes: Difference between revisions
(typo) |
(Fix some English wording and add timelines to milestones) |
||
| Line 1: | Line 1: | ||
== Goals == | == 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 | 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. | ||
== What to expect == | == What to expect == | ||
First we | 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 == | == Roadmap == | ||
=== M1: general correctness === | === M1: general correctness (1-2 months) === | ||
* Fix correctness bugs (making 2 processes correct). | * Fix correctness bugs (making 2 processes correct). | ||
* Ignore memory footprint. | * Ignore memory footprint. | ||
| Line 12: | Line 12: | ||
* Service/Shared workers in their own process. | * Service/Shared workers in their own process. | ||
=== M2: preparation for scaling === | === M2: preparation for scaling (3 months) === | ||
* Measure the memory footprint of content processes. | * Measure the memory footprint of content processes. | ||
* Start optimizing memory use. | * Start optimizing memory use. | ||
* Strategy to go beyond 2 content processes (aiming for 5 initially). | * Strategy to go beyond 2 content processes (aiming for 5 initially). | ||
=== M3: scaling === | === M3: scaling (ongoing) === | ||
* Currently vaguely defined, but the main focus will be memory optimization and the goal is to enable more content processes. | * Currently vaguely defined, but the main focus will be memory optimization and the goal is to enable more content processes. | ||
Revision as of 22:48, 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 sacrificing the advantage we currently have in memory usage compared to our competitors.
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: general correctness (1-2 months)
- 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 (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.
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 |
ts_pain tsvgx |
Running active web content
simultaneously in multiple tabs |
Bug tracking
Links
- Process Model (2012)
- Recent dev.platform discussion