1066792 - Group tabs into content processes more intelligently

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect, P3)

Description

[(not currently active) Ted Mielczarek]

Currently if dom.ipc.processCount > 0 and we load a new remote tab, we create a new content process if we haven't yet hit the limit, otherwise we pick a random content process and stick the tab in it:
http://hg.mozilla.org/mozilla-central/annotate/6a8b7740dc53/dom/ipc/ContentParent.cpp#l787

I think we should instead attempt to group tabs from the same origin in the same process. A straightforward way to do this would be to hash the origin in some way and use that to choose the content process to use.

Comment 1

[avada]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #0)
> 
> I think we should instead attempt to group tabs from the same origin in the
> same process. A straightforward way to do this would be to hash the origin
> in some way and use that to choose the content process to use.

That's a surefire way to make the worst/heaviest (eg: youtube) websites even worse.

Comment 2

[Gabor Krizsanits (INACTIVE)]

I think we have some competing goals here:
- keep related windows in same process (window.open + iframes) so we don't have to rely on CPOWs for their scripts.
- sandboxing
- performance

I think the second is mostly important for the same origin case. And since we have to consider navigation, at some point we will need to be able to move content between processes (that would also help later to gain performance by using smarter the available processes during runtime), but for start I would just make sure we keep related windows in the same process.

For sandboxing, I don't have a strategy yet. I think our current security layer between different origins is strong enough against script attacks, for crashes... I don't see a any good strategy that would help because of the limited process count but we'll see.

For the smart process usage I think we need to do some measurements first, and need the ability to move content from one process to another, and then we can start tuning our setup. I will file bugs about these.
As a start we might want to monitor the mem/cpu usage of each processes and take that into account when we pick an existing process to use for the new content.

Comment 3

[Jim Mathies [:jimm]]

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #2)
> I think we have some competing goals here:
> - keep related windows in same process (window.open + iframes) so we don't
> have to rely on CPOWs for their scripts.
> - sandboxing
> - performance
> 
> I think the second is mostly important for the same origin case. And since
> we have to consider navigation, at some point we will need to be able to
> move content between processes (that would also help later to gain
> performance by using smarter the available processes during runtime), but
> for start I would just make sure we keep related windows in the same process.
> 
> For sandboxing, I don't have a strategy yet. I think our current security
> layer between different origins is strong enough against script attacks, for
> crashes... I don't see a any good strategy that would help because of the
> limited process count but we'll see.

The sandboxing team has one ask here - give us a single content process that handles accessing local files (file:///) and direct all related local file loads in that process. The reason being - we'll need to lower the security of this process somewhat to support local file traversal and reads.

Comment 4

[David Bruant]

This is probably a duplicate of bug 1456959

Comment 5

[Andrew McCreight [:mccr8]]

(In reply to (not currently active) Ted Mielczarek from comment #0)

I think we should instead attempt to group tabs from the same origin in the
same process. A straightforward way to do this would be to hash the origin
in some way and use that to choose the content process to use.

I'd say this has been done quite thoroughly by Fission.