[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mat-dev] Test case for leak detection algorithm
|
Hello Krum,
Tsvetkov, Krum a écrit :
> 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.
I was indeed suspecting something like that.
> 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.
Yes :)
> 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.
ok, I will give it a try.
> 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.
You are welcome.
I hope as well that a workaround could be found.
It might allow me to reduce SAT4J (hence p2) memory footprint.
Thanks for your quick feedback!
Daniel
> Regards,
> Krum
>
> -----Original Message-----
> From: mat-dev-bounces@xxxxxxxxxxx [mailto:mat-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Tsvetkov, Krum
> Sent: Montag, 22. Juni 2009 15:32
> To: Memory Analyzer Dev list
> Subject: RE: [mat-dev] Test case for leak detection algorithm
>
> Hello Daniel,
>
> I was able to reproduce the problem on my box. This shouldn't be the
> normal behaviour. I will have a more detailed look why this happens and
> will write back once I have more information.
>
> Thanks for giving us the feedback!
>
> Krum
>
> -----Original Message-----
> From: mat-dev-bounces@xxxxxxxxxxx [mailto:mat-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Daniel Le Berre
> Sent: Sonntag, 21. Juni 2009 23:12
> To: mat-dev@xxxxxxxxxxx
> Subject: [mat-dev] Test case for leak detection algorithm
>
> Dear MAT developers,
>
> I gave a try to MAT on SAT4J under heavy duty
>
> Memory Analyzer (Incubation) 0.8.0.200906082011
>
> I generated a dump as suggested in Ian Bull blog:
> http://eclipsesource.com/blogs/2009/06/20/eclipse-galileo-feature-top-10
> -list-number-5/
>
> The dump is available here:
> http://www.sat4j.org/heap.bin.gz
>
> If I try to detect memory leaks on that dump, the leak detection
> algorithm cannot complete its task in reasonable time (it ran during at
> least 15mn on my PIV 3GHz). I have to quit eclipse to stop the process
> (pushing the cancel button has no effect).
>
> The dump is unusual I guess because there is a very high number of one
> single kind of objects (the constraints).
>
> I am wondering if there is a hope to be able to use MAT on such kind of
> dumps at some point or if those cases cannot be analyzed efficiently
> under current knowledge (i.e. limitation due to the complexity of the
> algorithms used).
>
> Cheers,
>
> Daniel
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mat-dev mailing list
> mat-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mat-dev
--
Daniel Le Berre mailto:leberre@xxxxxxxxxxxxxxxxxxx
MCF, CRIL-CNRS UMR 8188, Universite d'Artois
http://www.cril.univ-artois.fr/~leberre
