Electrolysis/Firefox

Background

This is the home page for all things relating to getting Firefox up and running with Electrolysis. The Mozilla platform will use separate processes to display the browser UI, web content, and plugins. The working name for this project is Electrolysis, sometimes shortened to e10s.

Status

We are currently in the planning phase.

Goals

There are number of things we believe the e10s project will give us (ordered in relative priority).

• Better application UI responsiveness.
• Improved performance, especially on multi-core machines.
• Better memory core stats.
• Crash resilience. A web content crash doesn't take down the entire browser.
• Preparation for sandboxing. Web content can be sandboxed more cleanly.
• Better visibility into how resources are being used.

The #1 driver for e10s is to improve the application responsiveness, or the perception thereof.

Non Goals

• Security improvements are a non-goal for e10s. We do believe that this project will net some security gains but it's not an explicit goal. In general the app should be no less secure than Firefox 4 but there is no additional security bar.

• There are 2 areas that are not really addressed by e10s but could possibly be effected. They might improve or they might degrade when we turn on e10s. A a minimum, we would want the following measurements to be equal to the Firefox 4 performance.
  • Page load time
  • Startup time

Targets

There has to be a way to quantify our e10s goals not only to know we have been successful but also to know when we are done. This involves understanding what metrics and targets will be measured to enable us to determine we have been successful in achieving the goals outlined above.

<insert targets here>

We also understand there will be some costs to certain areas in performance and memory consumption.

<acceptable tradeoffs>

<areas where perf can't degrade>

Risks

There are a number of problem or risk areas we have identified that will have to be tackled early on in the project. Some we understand how to mitigate, others we are not sure.

• 1. What are all the places that chrome touches content?
  • We really don't have our head wrapped around this.
  • We can instrument the code to tease out some of this information and the patterns.
  • We need to engage people familiar with this code to participate in early discussions and help tease out the highly interactive areas.

• 2. Extension Capability
  • We need a migration path and plan for this.
  • We need some developer outreach to help us figure out the right strategy.
  • We need developer friendly solutions.
  • Good documentation, guides to porting.
  • Add-on team should be involved in this.

• 3. Risk of performance impact
  • We can help this by having clear benchmarks early with tools in place to measure them.
  • We can be measuring regressions very early on.
  • Architecturally we need to be thinking about solutions that will minimize the need to go between the parent/child processes.
  • Responsiveness is clearly the priority and architecturally things don't have to be as pretty and refined.

• 4. Goals, metrics and measurements
  • We need clear goals, metrics and measurements at the beginning of the project.
  • It's clear what we are aiming for and going to measure.

• 5. What scale of architectural change is required in certain areas?
  • Figure out early on what areas are easy to change and what areas are going to have to be rewritten completely.
  • There should be correlation between this and identifying the things that cross content-chrome boundaries.

• 6. Existing test coverage
  • Are there things we were not testing before that we should be now.
  • Find the areas that don't have test coverage.

• 7.

Implementation

The implementation path will take a phased approach. Beyond Phase 1, we have not fully planned this out so more detail will be added as we make progress.

• Phase 1: Get Firefox up and running with e10s turned on.
• Phase 2: Cleanup what was done after Phase 1.
• Phase 3: Make the browser work properly. Start to think about parallel projects, testing, metrics.
• Phase 4: ...
• Phase 5: ...

Questions

There are some big open questions around the implementation details and approach. These are not fully formed but we are keeping track of them since more stuff will come up as we complete Phase 1.

I have put together a page with all the musings