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
There are many strategies to choose from. The (practically) unlimited process count is on some platforms not a realistic goal, and having a separate process for each open site instances or even sites does not seem like a reachable goal (for now at least). Which means using content processes as a security membrane cannot be a goal either. With limited process count probably content-process crash or hangs will still affect other tabs as well, but at least not all of them. We should find a way to crash content processes gracefully as much as it's possible.
Memory management
Memory cost of a content process Seems to be relatively high right now. Memory usage of e10s compared to other browsers gives us some breathing space.
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.
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 strategy
Google already did the research in 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.
Performance
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
- Main tracking bug: bug 1207306
- Initial bug prioritrisation
Add-ons status
It is yet to be investigated. WEAPI related tests seems to be broken with the multiple content processes and SDK based add-ons probably come with a big memory overhead per process.
Roadmap plan
To be decided.
Links
- Process Model (2012)