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).
Pros:
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.
Cons:
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.
Actions
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!