| Histogram and Dominator_Tree [message #11117] |
Wed, 17 June 2009 03:56  |
Eclipse User |
|
|
|
Thanks a million for prividing such a good tools in solving my real life
problems. I have applied MAT in analysis of memory leak at work. It really
helps.
I follow instructions online and those blogs I can find in SAP. I still
got some problems with using this great tool during the time I am
searching memory leaks.
First one is why MAT provides two editors Histogram and Dominator_Tree and
what are they good for?
Second one is how the retained heap are calculated in two
editors(diagrams)as I found different componets stay on top in these two
diagrams when I try to group them by calss loader or by class , or by
package. It seems to me that the retained size in Dominator_Tree is
calculated by accumulating lagest objects according to their
classifications and for Histogram,I think the calcuation is by other means.
Thanks in advance.
|
|
|
| Re: Histogram and Dominator_Tree [message #11122 is a reply to message #11117] |
Wed, 17 June 2009 11:59  |
| Eclipse User |
|
|
|
> First one is why MAT provides two editors Histogram and Dominator_Tree and
> what are they good for?
Both are views on the same base data: the histogram is aggregates data on
class level. So for each class you see the class name, the number of
instances and the shallow size. The last column contains the retained size
- this is the heap that would be freed if all of those objects were
garbage collected. Remember that this number includes also objects that
are referenced from more than one object represented by this row.
The dominator tree on the other hand looks at individual objects. The next
level are the objects that would be garbage collected if the parent node
would have no reference. And that is true for every level. That means if
you pick the top level object (and remove all references to it), then all
objects in the tree below are removed.
> Second one is how the retained heap are calculated in two
> editors(diagrams)as I found different componets stay on top in these two
> diagrams when I try to group them by calss loader or by class , or by
> package. It seems to me that the retained size in Dominator_Tree is
> calculated by accumulating lagest objects according to their
> classifications and for Histogram,I think the calcuation is by other means.
The retained size is always calculated the same way:
(i) remove all references to the object or the set of objects
(ii) form the Garbage collection roots mark all reachable objects
(iii) the retained size is the sum of all objects not marked
The difference can come from this scenario:
A -> B <- C
Object A and C reference B.
The retained size of A does not include B, because B is still alive via C.
The retained size of C does also not include B, because it is still alive
via A
The retained size of A and C contains B, because now it is not reachable
anymore.
Basically, if A and C are of the same class (say java.lang.String) then
the retained size in the String row also contains B.
In the dominator tree, you would find A, B, C on the top level. Of course,
if you group here, then A and C are grouped, but do not include B. Why? To
include B is an expensive operation so it's not easy to do. And often you
don't really need this (margin of error is about 3 to 5 percent).
I hope I was able to shed a little bit of light. :-)
|
|
|
| Re: Histogram and Dominator_Tree [message #11135 is a reply to message #11122] |
Thu, 18 June 2009 05:19 |
| Eclipse User |
|
|
|
Andreas Buchen wrote:
>> First one is why MAT provides two editors Histogram and Dominator_Tree and
>> what are they good for?
> Both are views on the same base data: the histogram is aggregates data on
> class level. So for each class you see the class name, the number of
> instances and the shallow size. The last column contains the retained size
> - this is the heap that would be freed if all of those objects were
> garbage collected. Remember that this number includes also objects that
> are referenced from more than one object represented by this row.
> The dominator tree on the other hand looks at individual objects. The next
> level are the objects that would be garbage collected if the parent node
> would have no reference. And that is true for every level. That means if
> you pick the top level object (and remove all references to it), then all
> objects in the tree below are removed.
>> Second one is how the retained heap are calculated in two
>> editors(diagrams)as I found different componets stay on top in these two
>> diagrams when I try to group them by calss loader or by class , or by
>> package. It seems to me that the retained size in Dominator_Tree is
>> calculated by accumulating lagest objects according to their
>> classifications and for Histogram,I think the calcuation is by other means.
> The retained size is always calculated the same way:
> (i) remove all references to the object or the set of objects
> (ii) form the Garbage collection roots mark all reachable objects
> (iii) the retained size is the sum of all objects not marked
> The difference can come from this scenario:
> A -> B <- C
> Object A and C reference B.
> The retained size of A does not include B, because B is still alive via C.
> The retained size of C does also not include B, because it is still alive
> via A
> The retained size of A and C contains B, because now it is not reachable
> anymore.
> Basically, if A and C are of the same class (say java.lang.String) then
> the retained size in the String row also contains B.
> In the dominator tree, you would find A, B, C on the top level. Of course,
> if you group here, then A and C are grouped, but do not include B. Why? To
> include B is an expensive operation so it's not easy to do. And often you
> don't really need this (margin of error is about 3 to 5 percent).
> I hope I was able to shed a little bit of light. :-)
Yes, it gives some insights about MAT. Generally I think the
functionalities of these two views overlap when group by
classloader/package/class, and in my point view domonator tree seems to be
a better start point for solving problems as it gives a consice
presentation of the base data.
|
|
|
Powered by
FUDForum. Page generated in 0.02969 seconds
Home