Closed Bug 675098 Opened 11 years ago Closed 5 years ago

VTune Amplifier XE support


(Core :: JavaScript Engine, defect)

Not set





(Reporter: sfink, Unassigned)




(1 file)

We need to update our support for VTune. One part is start/stop/pause/resume (or perhaps only pause/resume; I think they may have removed the start/stop API entirely.) Another is JIT code registration.
I finally landed some basic JIT-observing infrastructure in bug 645887.

It is... not exactly straightforward to use. I have example clients of it for valgrind, opagent (oprofile), and gdb. valgrind is easy, since currently all it can handle is "this address range has new code in it; forget what you knew about its previous code". I haven't really updated opagent to the new scheme, so it's not entirely right. My main test case has been gdb, which I'm feeding a bunch of different sorts of information.

The main wrinkle is functions that get inlined by the JIT. Our JIT now does this, and the inlining can nested fairly deeply (I'm not sure how far.) So previously it was a simple "address range x-y is associated with javascript function f() at line 17". Now, that address range is subdivided into multiple regions (which, for now, are at least contiguous, though that may change with our next JIT engine that I don't want to even think about yet.)

So right now, the API exposes some pretty raw internal datastructures from the Jägermonkey JIT compiler, and expects the consumer to analyze them to figure out what it needs. I'll post my work-in-progress patch for gdb that does this in a minute or two at bug 642320.

Inlining is (or has the potential to be) a little more pervasive with the JIT setup than with a traditional language, because we don't really see much of a distinction between a library's code and the "main" code. So, for example, I would expect many calls to jquery functions to end up getting inlined into the caller.

For now, I am only telling gdb the exact original filename:lineno for each address. For full support, it has the capacity to know that address 0x12345abcd is in the body of g() where it is inlined into f(), so that it can display a fake f() frame on the call stack, but I'm not doing that for now. To be honest, I haven't even tested the inlined frame stuff with gdb, but I expect that right now right now you'd just see caller1 -> g instead of caller1 -> f -> g. Which is confusing when you read the source code of caller1, as there's no invocation of g() anywhere in it.

I imagine the same situations apply to the Amplifier API.
Pinging this (and maybe taking it over).  --enable-vtune doesn't work at all right now on Windows; the version of VTune it was built for is very old.  We have Mozilla site licenses for VTune Amplifier (see intranet/Tools/VTune), and we should really update our support if at all possible.

(One note: on windows, VTune is installed in Program Files (x86), so we can't hardcode Program Files.  Also need to select lib32 vs lib64 appropriately.)
OS: Linux → All
Hardware: x86_64 → All
Summary: VTune support → VTune Amplifier XE support
Note that Bug 891541 added (now old) VTune support for OdinMonkey on release. The relevant VTune files have already been imported into our tree in js/src/vtune/, but they need updating.
Assignee: general → nobody
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1332466
You need to log in before you can comment on or make changes to this bug.