[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mat-dev] Test case for leak detection algorithm
|
Hi,
Regards,
krum
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