v8 findleaks command about llnode HOT 7 OPEN

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.

from llnode.

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)

from llnode.

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.

from llnode.

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 ?

from llnode.

@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.

from llnode.

This has to be rewritten: https://github.com/indutny/core2dump

from llnode.

@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.)

from llnode.