Future plans for "Out of the process add-on"'s

Skip to first unread message

Irakli Gozalishvili

Nov 16, 2011, 2:33:58 PM11/16/11
to Jetpack
Hi Folks,

As you might already have heard, [electrolysis](https://wiki.mozilla.org/Electrolysis) effort has been suspend in order refocus on other responsiveness issues (See for details: https://groups.google.com/forum/#!msg/mozilla.dev.planning/4q7SW89MjQY/7f1KConKZLEJ). We held a meeting to discuss impacts of the above mentioned decision on our plans of supporting electrolysis (Out of the process add-ons). We discussed pros and cons of this:

Out of Process Add-ons:

There are plugin process and add-on processes. Plugin processes are there to save the browser from a plugin crash. Add-on processes are there to run JavaScript, while they are not strictly necessary to stop the UI from blocking (long hangs get caught by the long-running script detector, but short hangs don't get caught by that detector), that's only visible way to prevent scripts from hanging the browser for a short period of time (which is a source of browser responsiveness issues).

  • Much of the add-on code runs in a separate process so cannot hang the UI for short periods of time.
  • Has security benefits because we only need to provide what they need to add-ons in the add-on process.
  • Gets around the problem with blocking file I/O.

  • Even with add-on processes some part of the add-on will run in the main process (pagemods) and can hang the UI from there.
  • Makes the APIs more complicated than they need to be.
  • The e10s code would likely need to be maintained by us.
  • Since E10S work is suspended no XPCOM e10sification is expected, which means we would have to do lots of message passing to do anything XPCOM related.
  • Windows 8 Metro may not support additional processes.
  • Performance and memory costs.

Further thoughts:
  • Is e10s likely to come back? What design decision do we make based on the current positioning.
  • Async APIs are better for forwards compatibility but more complex.
  • Sticking with async APIs is complicated for add-on developers.
  • Could diverge from the existing e10s APIs now to do our own more streamlined thing.
  • Need better performance measurements for Jetpack.
  • What are our main priorities and how does e10s fit into it?
  • Do threads give us similar benefits without the same overhead?
    • Performance-wise probably.
    • Not stability-wise but maybe that isn't as important to us.

Future direction:
  • Continue work on keeping the platform separated allowing for out of process / thread / worker support.
  • Start taking some measurements the performance of the platform.
  • Consider whether to start work on a prototype for running add-ons in their own thread.

  • Mossop to start working on performance tests for the platform.
  • Eddy to gather any final useful numbers from the OOP prototype.

If you think there is something on the cons / pros side that has not been listed above please let us know! 

Reply all
Reply to author
0 new messages