Re: [mat-dev] Test case for leak detection algorithm

[Chris Aniszczyk <zx@xxxxxxxxxxxxxxxxx>]

On Tue, Jun 23, 2009 at 10:22 AM, Tsvetkov, Krum <krum.tsvetkov@xxxxxxx> wrote:

Hello Daniel,

I have some better explanation for the problem, however, no really good
solution for the moment.

In your heapdump, the leak suspect is not a single object, but a group
of over 160.000 objects from the same class. Once we find the suspect,
we attempt to provide in the report some information about the paths to
the suspect. As there are many objects in the suspect, what the tool
does is calculate only the shortest path from the GC roots to each of
them and then try to merge the paths in order to show the common part.
This could be a rather costly operation, therefore the tool takes
randomly only 10.000 out of the 160.000 objects, and calculates the
paths to them. This usually works pretty well. We also try to cache the
already found paths and reuse them during the computation.

However, in your heap dump there are over hundred thousand different
reference chains to every of the objects of interest, which happen to be
processed before we find the cached path. And thus, the calculation of
each path takes between 0.3 and 0.5 seconds on a relatively good PC.
Doing this for 10.000 objects will take time.

The optimal solution (which I don't have :-) ... yet ...) will be to
find a better algorithm for the heavy computation I am doing. This may
need some time, and at the end I'm not sure I could make it at all. At
least I have a very good example now.

A not so optimal solution, but something you can use as a workaround for
now, will be to use the "Find Leaks" query instead of running the "Leak
Suspects" report - see attachment. There you can specify the maximum
number of paths to be calculated (the parameter "-max_paths"). Reducing
the value there can help get a result for your heap dump faster.

Thanks again for giving the feedback and the sample dump. I hope I could
give you a reasonable workaround for now. And I also hope we'll be able
to find some reasonable general solution for this.

Should a bug be filed so people interested in this can track it?

Cheers, 

-- 
Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
http://twitter.com/eclipsesource | http://twitter.com/caniszczyk