Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mat-dev] Test case for leak detection algorithm
Hi Daniel,

If memory usage is your concern, than you might want to use a different approach anyway. 
Check for example my blog post at  http://kohlerm.blogspot.com/2009/03/leaks-are-easy-to-find-but-memory-usage.html.

I planned to describe the most common anti-patterns on my blog, but so far I didn't find the time :(

Another common idea is to look for opportunities to apply lazy initialization:  http://kohlerm.blogspot.com/2009/04/analyzing-memory-usage-off-your-android.html. 
A common way to find some of those opportunities is to check for empty collections/arrays. MAT has a command for that. 

I have the dump already, let's see whether is find some time to look at it, and give you some hints ...


Regards,
Markus

On Tue, Jun 23, 2009 at 8:23 PM, Daniel Le Berre <leberre@xxxxxxxxxxxxxxxxxxx> wrote:
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
_______________________________________________
mat-dev mailing list
mat-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mat-dev

Back to the top