JS_DumpHeap ( https://developer.mozilla.org/En/JS_DumpHeap ) is supposed to "Dump the object graph of heap-allocated things", but in reality, it prints one arbitrary path to each object in the heap, rather than a complete graph. This makes it hard to use for leak finding, where you might want to ask a question like, "What are all of the JS roots that are holding on to this particular object?".
In bug 680482, I'm planning on a lower level rewrite of JS_DumpHeap that actually dumps an object graph. With the cycle collector, a tool like this, plus accompanying analysis scripts written outside of the browser, have proven to be quite useful for leak hunting. I can probably write a script to recreate the current functionality of JS_DumpHeap, which has a lot of dials that can be adjusted. I can leave the existing JS_DumpHeap in place if it is useful for people, for instance, by invoking it in the debugger.
I'm just how people use JS_DumpHeap for, and what sort of additional features they would be interested in seeing, or any other kind of feedback on JS_DumpHeap.
----- Original Message -----
> Hm, what is wrong with calling JS_DumpHeap with thingToFind set to the
> object in question?
As a general philosophical point, I'd like to make the browser code as simple as possible. Changes to the browser require administrative overhead, and risk breaking things (though not really in the case of JS_DumpHeap, which is only in debug builds). Furthermore, any more complex analysis is likely to be found later to be insufficient. This can be seen in the signature for JS_DumpHeap, which has a huge number of options, but even given all that was not sufficient for my recent attempts at leak hunting.
Here are some specific difficulties I had with using JS_DumpHeap for leak hunting:
- JS_DumpHeap treats grey roots the same as black roots, but for leak hunting, only the latter may matter. I was able to hack around this by temporarily disabling gcExtraRoots around JS_DumpHeap, but this probably excludes some black roots, too. I guess I could deal with this in a post-processing script like I do for the new DumpHeap, so maybe this is not a real issue.
- If you aren't using the debugger, how do you set thingToFind to something useful? I recently was trying to find out what was holding onto a ChromeWindow, but I wasn't sure to dig that out of whatever place in XPConnect land I was. I ended up adding code to set the first object with a description "ChromeWindow" to be thingToFind, which sort of works, but then I used it later and there were two ChromeWindows leaking, so how do I get detailed information on the second one? What if you decide later that you are interested in another object? You are out of luck.
- If you just want every root holding onto an object, JS_DumpHeap produces way too much information. I don't care about every path from this one root to the object I'm interested in. I uncapped the max depth JS_DumpHeap and I ended up having to kill the process after it had dumped 2 gigs of log file. I ended up setting it to something like 4 and it worked okay, but what if there was another root that was 8 steps away? Fortunately, in my case finding the one root at 4 was enough.
- Ultimately, I would like to integrate GC heap analysis with CC heap analysis. It would be nice to say "what is keeping this nsGlobalWindow alive?" and to have a script look in a CC heap dump to see what is keeping the window alive according to the CC. If the script sees that the GC is keeping it alive, it could then analyze the GC graph to see what is happening. The CC works "offline", so any GC heap analysis would also have to be offline. (With the new GC heap dump, I'm actually almost at the point where I can do this hybrid analysis.) An alternative would be to write a JS_DumpHeap-like functionality for the CC, but I'd rather avoid adding more C++ code if I can.
> >I can leave the existing JS_DumpHeap in place if it is useful for
> >people, for instance, by invoking it in the debugger.
> Please keep it - I use it in the debugger rather often.