Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Memory Analyzer (MAT) » Histogram and Dominator_Tree
Histogram and Dominator_Tree [message #11117] Wed, 17 June 2009 07:56 Go to next message
lsq  is currently offline lsq Friend
Messages: 40
Registered: July 2009
Member
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 15:59 Go to previous messageGo to next message
Andreas Buchen is currently offline Andreas BuchenFriend
Messages: 123
Registered: July 2009
Senior Member
> 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 09:19 Go to previous message
lsq  is currently offline lsq Friend
Messages: 40
Registered: July 2009
Member
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.
Previous Topic:cannot run MemoryAnalyzer on hp-ux
Next Topic:MAT not in Galileo?
Goto Forum:
  


Current Time: Fri Nov 08 22:01:50 GMT 2024

Powered by FUDForum. Page generated in 0.02726 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top