Right now we have a lot of APIs and functionality running in the parent process. All of the code implementing this constitutes a pretty big attack surface. It also means that we don't get to take advantage of the OS scheduler to make sure that applications get the appropriate number of cycles. When code supporting the features that the applications are using are running in the child process, it means that applications effectively steal cycles from the parent process. Additionally, gecko is pretty bad at prioritizing work items, compared to the OS scheduler currently has a much better understanding of what work tasks belong to what application. Memory management when we are going through the parent process is also a problem. In an emergency situation we can't really recover data that the parent process has allocated. A child can be immediately shut down, but in the parent we have to wait for a GC and hope that that gets us data back. Additionally, a leak in the parent is a permanent leak. A leak in the child goes away when the child process is terminated. Also, when IO happens through the parent process, it can mean that we allocate data in multiple copies. This bug is intended to track work items for things that we can push out of the parent process. It's great when we can push things to the child process, as long as that can be done without expanding the OS-level capabilities of that child process. In other cases we might need to set up dedicated separate processes which can own certain work tasks. What we can do for each separate API/functionality will vary from case to case, so lets debate what to do in the various dependent bugs.
5 years ago
Depends on: 896885
5 years ago
Depends on: 898694
This is likely just something to close, but assigning to myself in case there are any dependent bugs that are important for sandboxing.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 17 days ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.