407542 - Add DTrace probes for XPConnectWrappedJSClass

Status: RESOLVED WONTFIX

(Core :: XPConnect, defect)

Description

[Robert Sayre]

Currently, JS profiles report misleading entry points because they miss the js_Invoke call in XPConnect.

Comment 1

[Robert Sayre]

Attachment: Add probes to XPC

I'm not sure what the best way to get the right visibility for the C functions is. Maybe just stick them in an xpc .h file and extern them? Right now I get:

21256 mozilla68885 libxpconnect.dylib _ZN19nsXPCWrappedJSClass10CallMethodEP14nsXPCWrappedJStPK19XPTMethodDescriptorP17nsXPTCMiniVariant [nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)] xpc-wjs-entry
21257 mozilla68885 libxpconnect.dylib _Z23mozdtrace_xpc_wjs_entryP9JSContextPKcS2_ [mozdtrace_xpc_wjs_entry(JSContext*, char const*, char const*)] xpc-wjs-entry

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

There's some patch bit-rot; I'm assuming the intent now would be to move to using javascript-trace.d instead of mozilla-trace.d.  I have started to update the patch, but...

On OS X (10.5.2  and earlier, at least) there is a serious problem with reusing the same probe provider definition for multiple libraries.  Namely, it doesn't work.  Each library provides its own DOF (DTrace Object File), and although dyld gathers these up into a single list, they are still processed sequentially.  Once the first USDT provider with the given provider name ('javascript' in this case) is loaded and its probes initialized, all subsequent providers with the name (and their probes) will be ignored.  On my system, this manifests as libmozjs.dylib's probes showing up, but not libxpconnect.dylib's.  If you hack the strtab in the DOF file in libxpconnect.dylib to use "wavascript" instead of "javascript", however, things are happy (although your probe-specs may not match.)

fasttrap.c :: fasttrap_meta_provide in an ifdef __APPLE__ segment is the guilty party, bailing because ftp_mcount is non-zero.  There's a comment in there about why they do that for cost reasons, and interestingly, also about how they don't bother to deal with duplicate probes (bug 403132; although they are sorta right; it's a linker bug that causes them anyways).

This raises the question as to whether the correct solution is to vary the provider names, or to refactor things so that the probes are only ever fired from inside libmozjs.

Comment 3

[Robert Sayre]

We want to keep the xpconnect probes in a separate provider, because Sun uses the spidermonkey probes in other embedding environments. A common provider for Mozilla probes will be handy, so let's make one in probes/.

Comment 4

[John Rice]

Robert - I'd like to get the load probes landed as they have been languishing a bit. I've been off in Mercurial land for the last 6 months.

Could we incorporate your probes into this patch, to have a common provider for these Mozilla probes?

https://bugzilla.mozilla.org/show_bug.cgi?id=401697

Comment 5

[Robert Sayre]

I this patch has been superseded by other work.

Comment 6

[Robert Sayre]

Rather, I think this patch has been superseded by other work.