1493169 - Consider putting all things that should be sharing an Xray's expandos into a single compartment

Status: NEW

(Core :: XPConnect, enhancement, P3)

Description

[Boris Zbarsky [:bzbarsky]]

Once we can do multiple globals per compartment, would it make sense to use a single compartment for all system code?  Or at least for all the things that might want to share expandos on an Xray?

The goal would be to get rid of Xray expando chains and just always have the expando object hang off the holder.

Maybe we're already there with all JSMs sharing a global...

Comment 1

[Bobby Holley (:bholley)]

Yeah, this was only ever really needed for system compartments. If we get to (or already are at) the point where all non-sandbox system principal code is running in the same global, we can just do this.

That said, it might be a bit less risky to wait for Jan's stuff.

Comment 2

[Kris Maglione [:kmag]]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #0)
> Once we can do multiple globals per compartment, would it make sense to use
> a single compartment for all system code?  Or at least for all the things
> that might want to share expandos on an Xray?

Definitely. We should do this even if we don't care about X-ray expandos. The cross-compartment overhead between browser window and JSM scopes still adds up to a lot.

(In reply to Bobby Holley (:bholley) from comment #1)
> Yeah, this was only ever really needed for system compartments. If we get to
> (or already are at) the point where all non-sandbox system principal code is
> running in the same global

We're close, but browser windows still each get their own compartment. I don't think we could get away with losing expando sharing for those.

We unfortunately also still have some system code running in sandboxes (mainly devtools, but also some extension framework code that an intern decided to move to a sandbox for some reason :/). That probably isn't relevant here, though.

Comment 3

[Kris Maglione [:kmag]]

(In reply to Kris Maglione [:kmag] from comment #2)
> (In reply to Bobby Holley (:bholley) from comment #1)
> > Yeah, this was only ever really needed for system compartments. If we get to
> > (or already are at) the point where all non-sandbox system principal code is
> > running in the same global
> 
> We're close, but browser windows still each get their own compartment. I
> don't think we could get away with losing expando sharing for those.

Although, realistically, with e10s maybe we can. There shouldn't be many places we need to deal with X-rays in the parent process anymore, and all chrome code in the content process should run in the same global now.

I suppose if we wanted to play it safe, we could just change the behavior of content processes to start with, and extend it to the parent process when we're sure it's safe.