llnode
llnode copied to clipboard
nodejs
v8 findleaks command
Could we have a v8 findleaks command, that found leaked objects? This might be something that requires v8 changes to understand allocations. Plenty of prior work in this area, of course, even one from my CEO: http://web.stanford.edu/class/cs343/resources/cs343-annot-purify.pdf
When would an object be considered leaked? With a GC, an object is either reachable from the root set or it's garbage - there are no malloc-without-free leaks like you have in C.
It is pretty much impossible to figure out, I'm afraid. The only way it could work is by comparing two core dumps and seeing which objects are common to both of them. Would this work for your use-case @brendangregg ?
I agree it's probably not possible to tell which objects are leaking from one dump.
Memory Analyzer for Java (http://www.eclipse.org/mat/) generates a dominator tree which shows you which references are keeping large chunks of the heap alive. For Java it's been an excellent technique for finding what's hanging on to object references and keeping large amounts of data alive. That often identifies the culprit in a leak situation from just one dump.
I think in both llnode and the v8 heap dumps we're missing the sort of detailed heap root information that we'd need to generate that though.
There's some background reading here: https://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.mat.ui.help%2Fconcepts%2Fdominatortree.html https://en.wikipedia.org/wiki/Dominator_(graph_theory)
@hhellyer Heap snapshots let you calculate the retained size of an object; sum its object graph and keep track of cycles. Is that what you mean?
Aside: I remember discussing turning core dumps into heap snapshots (with you? not sure). That would cover that use case.
@bnoordhuis - I don't think the two are quite the same the dominator tree algorithm works out which object is responsible for keeping that retained space alive. Memory Analyzer shows retained size too but the dominator tree view shows how things are kept alive. (I'm going to struggle to explain it properly - it's definitely worth reading up on or trying out in Memory Analyzer.)
By the way I implemented MAT's algorithm on V8 heap snapshots in JavaScript: https://github.com/joyeecheung/v8-mat
The algorithm probably does not work on core dump (or heap snapshots converted from core dumps) yet because we don't have enough GC root information in the post-mortem metadata (I suppose it should be possible to expose GC Root indexes to the metadata though). The algorithm starts by iterating the GC roots in the heap and look at their dominated nodes.
