413559 - Make XPConnect use faster accessors for JS parent, proto, private, and class slots.

Status: RESOLVED FIXED

(Core :: XPConnect, defect, P1)

Description

[Johnny Stenback (:jst)]

Attachment: Use the faster & smaller macros.

Now that the JS engine has obj->fslots that are safely accessable directly, we might as well make XPConnect do that to save on function call overhead and let the compilers optimize our code better. The JS engine contains STOBJ_GET_(PARENT|PROTO|PRIVATE|CLASS) macros that accesses obj->fslots[] directly, so XPConnect should do that too. The one exception is when accessing the private data, there we need the check that JS_GetPrivate() does, but that can be done in an inline function in xpconnect, and accessing the private data is something XPConnect does a lot, in tight loops etc, even. See upcoming patch. Accessing the slots directly also has the benefit of not needing a context pointer for the access, so that lets us remove the cx argument from some helpers etc, which means less code, and fewer instructions too.

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

The XOW, XPCNW and XPCWN changes make sense to me here (because of the guarantees we can make about the behavior of the underlying objects, even on multiple threads), but I worry about XPCSafeJSObjectWrappers being used on multithreaded objects and therefore racing. Am I missing some guarantee that prevents that?

Comment 2

[Brendan Eich [:brendan]]

mrbkap: racing how? Can you diagram a race that breaks anything?

/be

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 298548 [details] [diff] [review]
Use the faster & smaller macros.

I can't; not really sure what I was thinking before, so r=mrbkap

Comment 4

[Johnny Stenback (:jst)]

Fix checked in.