Electrolysis/Firefox

From MozillaWiki
Jump to: navigation, search

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 tracking a number of short term goals. These will help inform a longer term engineering plan and direction.
  • We are waiting on a couple of blog posts
    • Blizzard - e10s goals
    • Ted - e10s tools and measurements

Goals

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

  • 1. Better overall application UI responsiveness.
  • 2. Improved performance, especially on multi-core machines.
  • 3. Better memory core stats.
  • 4. Using more than 1 content process.
  • 5. Crash protection. A web content crash doesn't take down the entire browser.
  • 6. Preparation for sandboxing. Web content can be sandboxed more cleanly.
    • A goal for the security team is to prepare a threat model for e10s.
  • 7. Add ons/extensions (need a crisp goal defined here)

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

Other interesting gains but not explicit goals...

  • Better visibility into how resources are being used.

Non Goals & Assumptions

  • Specific security improvements are a non-goal for e10s although designing with security in mind is. The security team is planning on putting together a threat model. We do believe that this project will net some security gains. In general the app should be no less secure than the previous version of Firefox.

Meetings

Targets

In order to track how we are doing and know when it's time to declare success, there needs to be a way for us to quantify our e10s goals. This involves understanding what metrics and targets will be measured and build this into the implementation process.

Characteristics:

  • Overall Responsiveness
  • Page Load Time
  • Startup Time
  • IPC Measurements
    • Number of calls
    • Time to process a call

Core Measurements:

  • The UI should react to user actions within 50ms at all times.
  • Page content should react within 50ms, except in exceptional cases.
  • Scrolling should be handled within 10 ms.

Tools:

<insert descriptions of tools, existing and those which need to be built>

Memory Consumption:

<memory consumption tradeoffs>

Risks & Issues

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 help mitigate, others require some experiments to be run in order to give us more visibility.

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.
  • There are differing perspectives on the value of instrumentation for this purpose but there is agreement that providing us with more data is positive.
  • 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 needs to clear what we are aiming for and going to measure.
  • We need to start to measure early in the project so we can identify problem areas sooner.

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. Temptation to rearchitect everything

  • To help mitigate this we will require discipline and clear decisions.
  • We need to figure out all the pieces that we really need to have.
  • Some will have to be completely reworked, others less so.
  • Evaluating these decisions by making back to the larger project goals is key.

8. Current state of module ownership

  • Some areas that will be changing are in old code with no clear owner or expert.
  • Need to identify these up front.

9. Developer tools

  • The way in which developer tools are currently, they "have their fingers all over the content".
  • Right now they hook into the platform and front-end in ways that are hard to make asynchronous.
  • There should be an early project to explore this more fully so we can identify the hard pieces.

10. Impact to other apps

  • Lower priority risk.
  • It's true that there are other apps that might be affected SeaMonkey, Thunderbird.
  • Communicating to them is a bit like outreach.
  • We should remember to make as much of our work as visible as possible so they understand if they are impacted by any core changes.

11. Further changes to Platform

  • There is likely to be some changes needed for Firefox that we did not identify as part of the Mobile project.
  • We don't anticipate this to be a high risk area but wanted to note it.

Implementation

There seems to be wide agreement that implementation path will take a phased approach. The early iterations will help us answer some of the big questions and refine the plan. I have intentionally left anything beyond Phase 1 a blank for now.

  • Phase 1: Get Firefox up and running with e10s turned on with an eye towards early experiments we need to be doing to answer some larger questions and mitigate risks.
  • Phase 2:
  • Phase 3:
  • Phase 4: ...
  • Phase 5: ...

Brainstorming

In the course of my discussions with people, there are some big open questions around the implementation details and approach. I wanted to capture some of these musings for completeness - musings

Retrieved from "https://wiki.mozilla.org/index.php?title=Electrolysis/Firefox&oldid=329481"