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
- Short term
- Low hanging fruit we can do to improve the experience quickly for testers
- Long term
- TBD
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
NUWA
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 Nuwa which is based on copy-on-write forking mechanism that is provided by Linux. Windows have a quite different API to share memory between processes and it has to be investigated if it's usable for Nuwa. Boost uses this API for memory sharing.
Lazy Sharing
Another approach was suggested by Till Schneidereit lazy cross-process memory sharing. We also want to monitor the resource usage of each sub-process bug 1255843 which will open doors for further optimization strategies.
Process Allocation
Google researched this area and came up with various 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.
Other Problem Areas
Areas of the browser which may be incompatible in some way with multiple content processes.
- Plugins
- Dev Tools / Browser Content Toolbox
- 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.
- Running WE add-ons in separate processes?
- Do e10sified legacy add-ons work?
- Do shimmed legacy add-ons work?
Testing
TBD
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
- Main tracking bug: bug 1207306
- Initial bug prioritrisation
Links
- Process Model (2012)
- Recent dev.platform discussion