[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mat-dev] Test case for leak detection algorithm
|
Hi Markus,
Markus Kohler a écrit :
> 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.
Thanks for the pointer.
> I planned to describe the most common anti-patterns on my blog, but so
> far I didn't find the time :(
I will check your blog regularly :)
> 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 will take a look.
> I have the dump already, let's see whether is find some time to look at
> it, and give you some hints ...
>
That would be fantastic!
Cheers,
Daniel
> Regards,
> Markus
>
> On Tue, Jun 23, 2009 at 8:23 PM, Daniel Le Berre
> <leberre@xxxxxxxxxxxxxxxxxxx <mailto: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>
> [mailto: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>
> [mailto: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 <mailto: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 <mailto:mat-dev@xxxxxxxxxxx>
> > https://dev.eclipse.org/mailman/listinfo/mat-dev
>
>
> --
> Daniel Le Berre mailto:leberre@xxxxxxxxxxxxxxxxxxx
> <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 <mailto:mat-dev@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/mat-dev
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
