Electrolysis/Firefox/BigQuestions

Questions

We have running list of questions that have come up over during many discussions. I tried to add in some of the thoughts as well but this is far from complete. We will tackle these over the course of our phased approach to implementing Firefox with e10s. In some cases we will change our mind and of course this list will be expanded.

1. Where are all the places that chrome touches content?

• Is there any value in looking at some automated way to get this information?
• There should be some way to instrument and identify the stuff that will be broken. It will give us a lot of good information but not everything.
• We cannot fix stuff in an automated way though.
• Best plan is still to get some initial FF running and see what we have to remove.
• Getting that baseline thing up and running enables us to move forward on other activities.
• Getting to this demo on the mobile side took about 2 weeks but we really have no idea how long it will take for FF.
• Other than resources, there are no blockers to this starting immediately.

2. What's lightspeed for cross process calls - IPC performance?

• I don't think anybody was willing to put a number on this.
• There was some number floated around (10ms) - for the parent process to handle calls but this probably doesn't quite answer the question.
• We can still learn some more from the mobile guys and we may need to start tracking some metrics to tease this out.

3. Where do we diverge with what mobile did and where can we converge?

• Agreement that getting FF running is a bigger project. There are many things that Fennec just didn't have to address.
• Everybody seems to think that taking the same approach is a good one.
• A lot of work was done already for Fennec that we will leverage.

4. Takeaways from mobile stuff?

• Deal with the tests earlier in the cycle. Mobile left this to the end.
• Figure out how to measure performance and targets. Page load on mobile regressed 2x.

5. What goes where? Copies? (ie: prefs, network, cache, plug ins, add ons)

• For Fennec we put network in the parent process.
• There are some questions about whether we should revisit this.
• Others think it's in the right place but there are still some sync calls we need to eliminate.
• The takeaway I got was that we should not worry about this. We have something working now, let's go with it.

6. What's the migration strategy for add ons?

• We know we are going to run into problems with ad ons.
• A lot of stuff will have to be rewritten.
• If it will be rewritten maybe we should take this opportunity to use jetpack for everything?
• Is there some policy decision we should be making here?

7. How many splits do we want to do? ie: 1 process per web page? 1 process per window?

• What are the security implications?
• When do we have to make this decision?
• Feeling is that we don't need to answer this right away.
• These are policy issues we can phase in later.
• After getting a parent/child up and running, adding subsequent children, shouldn't be that difficult.
• We shouldn't worry about trying to answer this question right now.

8. What is the mantra on security?

• Our focus should be on responsiveness initially.
• We may need to keep in mind security implications for some of the architectural goals.
• This is something we should tackle but later when we have learned more stuff (Phase 4).
• We want to be clear about what we are focusing on and not rat hole.

9. How we going to handle all the tests that will break?

• The tools team is already doing some work in this area.
• For Fennec we left the testing issue until the end.
• We don't want to approach the FF project the same way.
• Need to get a handle on all the tests that will need to be refactored early so we can phase this in with the rest of the project.

10. How do we measure responsiveness?

• No good tests that measure this exactly.
• There is a different between perceived performance and actual performance.
• Having a list of accompanying user scenarios may be helpful. Tab animation, startup, scrolling, back button, page load, any time the browser feels jumpy.
• Most people thought that testing responsiveness and performance was going to be challenging.
• We really need to start thinking about this.
• We don't want to start measuring stuff before we really have some way to test it.
• Some discussion of main event loop measurement as a reflection of how quickly the browser responds - tsnap.
• We are going to need a whole new set of performance metrics.

11. How do we measure memory fragmentation?

• Easy to measure this but hard to know what we do with the data.
• It will be difficult to quantify the target.

12. What are the scenarios that multicore will help with? What will the user experience be like?

• Some suggested scenarios...
  • Initial startup with 20 saved tabs
  • Interacting with one web page when another one is doing heavy JS.
  • Possible to instantly close the current tab.
  • No regressions against current performance.

13. Is there some project/decision to make about XBL?

• This is used a lot in FF front end.
• Some feel this is where many of the pains will occur.
• There might be a decision to be made; use XBL 2.0 or get rid of it.
• We have something implemented now to deal with the problem - involves everybody using the MessageManager.
• Is changing this a rearchitecture project vs something we really need to do for e10s.

14. How are we going to handle issues around accessibility and developers tools?

• Right now they hook into the platform and front-end in ways that are hard to make asynchronous.
• There could be stuff here that we haven't realized will be very complicated.
• Something we may need to think about early on.