566077 - Fix some small things Shark pointed out

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: testcase

I sharked this testcase for a while aiming to remove anything XPC*.cpp. It turns out that XPCWrappedNative::GetWrappedNativeOfJSObject is pretty slow, especially in cases that we know for a fact that we have a wrapped native. Also: XPCWrappedNativeScope::FindInJSObjectScope is slow (it does a linear search through the list of scopes?!).

Most of the winnings from this testcase should come from another fix I'll look for later: setting window.x should call XPC_XOW_SetProperty -> nsWindowSH::SetProperty -> set a normal slot. Right now: we go XPC_XOW_SetProperty -> nsWindowSH::SetProperty -> nsWindowSH::SetProperty (via the JS engine, which takes a very non-trivial amount of time) -> nsEventReceiverSH::SetProperty.

Also note: we don't trace this testcase at all: setting window.x knocks us off trace anyway because the global object is special. This is a separate problem from security wrappers.

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Avoid GetWrapperForObject

nsXPConnect::GetWrapperForObject is way overkill when we're wrapping the global object for its own scope.

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Avoid XPCCallContexts in same-origin XOWs

CallContexts should only be needed when we're calling directly into C++ ourselves. Otherwise, we'll go into the engine, which will have to go through XPConnect anyway, which will create its own callcontext when it's needed.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Avoid GetWrappedNativeOfJSObject

PCWrappedNative::GetWrappedNativeOfJSObject is slow. If we already have a wrapped native (especially in hooks like {inner,outer}Object) we should just get the wrapped native directly.

Comment 4

[Robert Sayre]

could you land these on the TM tree?

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/tracemonkey/rev/542a97d14871
http://hg.mozilla.org/tracemonkey/rev/52e046cb0317
http://hg.mozilla.org/tracemonkey/rev/be891c599b59

and bustage fix
http://hg.mozilla.org/tracemonkey/rev/f423fbc93e3f

I forgot to add the bug number to the commit messages, unfortunately :(

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

The original title of this bug was way too grandiose (and wanted to be a tracking bug). I'll tackle other stuff in other bugs.

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

This got pushed to m-c some time ago.