568968 - Optimize XPC_WN_JSOp_ThisObject to not compute things it won't need

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Blake Kaplan (:mrbkap) (inactive)]

Currently, the thisObject hook in XPConnect computes a bunch of stuff up front in order to call nsXPConnect::GetWrapperForObject. This includes getting the current subject principal (amongst other things). We should delay computing stuff as much as we possibly can. This should allow us to call the ThisObject hook without falling off trace.

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Possible fix

I haven't tested this at all (though I know the browser comes up). It isn't "clean" in that all it does is add another fast path, but I have another patch still in the works that makes nsXPConnect::GetWrapperForObject go away (in favor of XPCWrappedNativeScope::GetWrapperFor, which doesn't knock us off trace and doesn't call into the security manager at all).

I'll tryserver this, make sure it's doing what I want it to do, and request review.

Comment 2

[Johnny Stenback (:jst)]

This doesn't apply as is, I'm guessing it goes on top of some of your other patches, I think I've even seen the change that would make this apply, but don't have a bug number for it...

Comment 3

[Boris Zbarsky [:bzbarsky]]

This is a major slowdown when we hit it, which tends to be in poorly-written benchmarks (most of them).  We need to get this fixed....

Do jsreftests have access to jitstats?  Can we detect deep bails in jitstats?  As in, can we add a test for this?

Comment 4

[Damon Sicore (:damons)]

Is this really a blocker?

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

This is fixed by the compartments patch.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So should this depend on bug 558861?

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

bug 580128 is closer.

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

Fixed by brain transplants.