| Hi Kevin:
Thanks for these tips - the retained set helped. We were eventually able to track down the problem by using the ""Java Basics" -> "Open in Dominator Tree" option, which then displayed:
By expanding some of the String objects we can see they are referencing large backing character arrays. According to the Android Java String documentation:
"Multiple strings can share the same char[] because strings are immutable. The substring(int) method always returns a string that shares the backing array of its source string.
Generally this is an optimization: fewer character arrays need to be allocated, and less copying is necessary. But this can also lead to unwanted heap retention. Taking a short substring of long string means that the long shared char[] won't be garbage until both strings are garbage. This typically happens when parsing small substrings out of a large input.
To avoid this where necessary, call new String(longString.subString(...))."
So, we have changed some of our code to wrap calls to Matcher.group() with new String() as recommended here (group() results in a subString() call under the hood).
Once again, thanks for your help,
- Francis.
On 09/02/2012, at 4:39 AM, Kevin Grigorenko wrote: Francis,
MAT is showing that the HashMap @ 0xACE5CFB0 is retaining 115,395,160 bytes. You expanded down into a single HashMap$Entry @ 0xAF761F50 which retains 3,282,160 bytes. Most likely, the rest of the 115,395,160 bytes are retained in other HashMap$Entry objects in the HashMap (and remember that some implementations of HashMap do not have a flat Entry table, but in addition may have a next entry that creates a sort of tree of entries). It's also possible that the objects within this HashMap$Entry reference each other, and so there may not be a clear retainer. I would recommend showing the retained set of the HashMap to see the histogram of what it retains.
--
Kevin Grigorenko
IBM WAS SWAT Team
kevin.grigorenko@xxxxxxxxxx
Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/kevgrig/
<graycol.gif>Francis Crimmins ---02/07/2012 07:59:39 PM---Hi: I'm analysing my Java application for possible memory leaks and the MAT tool is telling me that
<ecblank.gif>
From: <ecblank.gif>
Francis Crimmins <fcrimmins@xxxxxxxxxxxxxx>
<ecblank.gif>
To: <ecblank.gif>
mat-dev@xxxxxxxxxxx,
<ecblank.gif>
Date: <ecblank.gif>
02/07/2012 07:59 PM
<ecblank.gif>
Subject: <ecblank.gif>
[mat-dev] Missing figures in "List objects with outgoing references" report?
<ecblank.gif>
Sent by: <ecblank.gif>
mat-dev-bounces@xxxxxxxxxxx
Hi:
I'm analysing my Java application for possible memory leaks and the MAT tool is telling me that some
"statistics" classes are taking up 189 MB of heap. When I select the "List objects with outgoing references" report
and start drilling down it suggests that the "ReferencedFileTypeStatistic" class is using up the memory.
However, when I expand this reference in the report the expanded figures do not add up to the total for
that object (see screenshot below):
<3C429733.gif>
As you can see, the total for the ReferencedFileTypeStatistic object is using 1,535,640 bytes. However, the individual
components do not add up to this total. Is this behaviour expected? The map, link_pattern and suffix_type_stat objects
are all ones I expect to see for this object and are approximately the right size.
So far MAT has proven to be a really useful tool and helped in identifying leaks so they could be fixed.
I'm at a loss to explain what is taking up the rest of the memory based on this report - any advice would be gratefully
received.
Kind regards,
- Francis.
--
Francis Crimmins
Phone: 0433-545-884
fcrimmins@xxxxxxxxxxxxxx | www.funnelback.com
Postal Address: PO Box 1441, Dickson, ACT 2602
Street Address: Unit 9, 20 Challis St., Dickson ACT 2602, Australia
_______________________________________________
mat-dev mailing list
mat-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mat-dev
|
