| RE: [mat-dev] Test case for leak detection algorithm |
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. 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 -- 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 _______________________________________________ mat-dev mailing list mat-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/mat-dev
Attachment:
call_find_leaks_query.jpg
Description: call_find_leaks_query.jpg
