Electrolysis/Firefox/20110603

Agenda

1) Review and update goals

• https://wiki.mozilla.org/Electrolysis/Firefox#Goals

2) Confirm technical constraints, state and next steps

• We would start with the following statements:
  • The overriding technical constraint is provide compatibility for as many extensions as possible.
  • The current technical state is that CPOWs will help:
  • https://spreadsheets.google.com/spreadsheet/ccc?key=0Ag3-54eJ7D8OdDZ1U09kVEl1UnZ4QU1wVU9yS2dBcGc&hl=en_US
  • Front end work acceleration would be very good, but is a separate issue.

Goals

• based on https://wiki.mozilla.org/Electrolysis/Firefox#Goals
• these are first step goals
• Better overall application UI responsiveness
  • yes, this is the overriding goal
  • this is the win
• Improved performance, especially on multi-core machines.
  • 4th on list
• Better memory core stats
  • need to be explicit - being able to exit content renderer - this is the real world of this goal
  • ben: requires multiple content processes
  • brend: this is a competitive must have (chrome, ie, safari)
• Crash resilience A web content crash doesn't take down the entire browser.
  • "crash protection" is the re-phrasing
• Preparation for sandboxing. Web content can be sandboxed more cleanly.
  • needs to be "crisped up"
  • architecture must allow for this
• add-on compatability is a goal during implementation
  • CPOWs flexibility is a win for some number of add ons

Backend Electrolysis Pieces

• not blocked by front end
• long poles (benjamin)
  • accessibility
  • developer tools
  • probably needs front end to stand up to really start
  • gfx, some work to do, well underway
  • content, js no real worries

Front End

• instrumenting number of crossover points for front end
  • needs measurement
  • if we need to lower the number of messages overall
    • different archictecture needed
  • docshell failures
    • require message manager even with CPOWs

Extensions

• The current technical state is that CPOWs will help: https://spreadsheets.google.com/spreadsheet/ccc?key=0Ag3-54eJ7D8OdDZ1U09kVEl1UnZ4QU1wVU9yS2dBcGc&hl=en_US
• of top 26
  • 5 may work with CPOWs
  • 7-8 don't touch content
• install an add on that is e10s incompatible, single process mode
  • jay: are we taking on a burden supporting this?
    • yes (blizzard, bsmedberg)
• brendan: be less reactive about extension compatability
• jay: js ctypes help
  • brendan why is this the case?
  • not a replacement for xpconnect
  • johnath: ctypes can help access 3rd party dll's that don't need to call back in
• 85% of users have installed an add on from AMO
  • much higher than previously though
  • brendan: what API's are being used?
  • ben: are hard to measure - event listeners can access docshell
  • brendan: should measure - up our game and not do this by hand
  • bz, dolske could give input
  • andreas make proposal
    • work with johnath's team
• decision: what kind of porting/help do we offer
  • will be driven by Andreas' data
  • measurement is key before CPOWs/front end re-write procedure

Response Time

• Bob's team on this
• need to know what to measure
• response delay with main event loop
  • debug assert for > 50 MS assert
  • 651580

Project Management

• • Sheila/Benjamin/Blizzard/JP will collaborate for now, sync in ~1 week
  • Blizzard has action items

Public info

• blogs
  • Goals (Blizzard)
  • CPOWs research (Johnath)
  • Response time tools (Ted will blog)

Next actions

• Build static analysis tools (agal & damon)
• Build dynamic instrumentation tools (bz, johnath, felipe, dietrich)
• Continue building out front end lab rat (felipe)
• Data for add-ons usage
• Responsiveness tools bring-up (bob)
• Flip memory and crash goals in the wiki
• Expand memory description