[#512] Retained size of object discrepancies

Questions about YourKit Java Profiler
Post Reply
vgritsenko
Posts: 26
Joined: Mon Jan 24, 2005 7:29 pm

[#512] Retained size of object discrepancies

Post by vgritsenko »

I'd think that retained size of any given object as shown in class tree view should equal to sum of its shallow size and retained sizes of all its members.

I have a case where class tree for an object shows object retained size of 1677680 bytes, its shallow size 224 bytes, and sum of its members retained size at 47184. This makes a difference of 1630496 bytes, and YourKit does not show where all these bytes were spent.
vgritsenko
Posts: 26
Joined: Mon Jan 24, 2005 7:29 pm

Post by vgritsenko »

Any opinion on this one? Is it a problem or am I wrong?
Vladimir Kondratyev
Posts: 1624
Joined: Tue Aug 10, 2004 7:52 pm

Post by Vladimir Kondratyev »

Any opinion on this one? Is it a problem or am I wrong?
You are wrong. Retained size of object is not a sum of its shallow size and retained sizes of all its members. Here is an example which demonstrate this situation:

Code: Select all

Root1          Root2
   |             |
   |             |
    +---->Obj0<--+
            |
            v
          Obj2 -> Obj3 -> Obj4 ->.....->Obj10000
ShallowSize(root1) == RetainedSize(root1) and it does not include ratained size of "Obj0" because Obj0 is references by Root2. Moreover retained size of Roo1 is _much_ less than retained size of Obj0.

Please try to read the bundled documentation which describes in detailes the nature of retained size.[/code]
vgritsenko
Posts: 26
Joined: Mon Jan 24, 2005 7:29 pm

Post by vgritsenko »

Ok, thanks for the explanation, and I think I've seen the picture in the docs.

However, there is slight complication here. Suppose you have SuperRoot on top with links to Root1 and Root2. Given that,

Retained(SuperRoot) = Shallow(Root1) + Shallow(Root2) + Retained(Obj1).

Now, when browsing SuperRoot, YJP correctly displays retained size according to the formula above. But when you try to dig deeper, it will show:

Code: Select all

Obj - Shallow - Retained
SuperRoot - Small - Huge
Root1 - Small - Small
Root2 - Small - Small
And this picture is misleading a bit. Not in the sense that it is not correct, but it does not provide a way to investigate memory consumption further, and it confuses (where those huge-small*2 bytes went?). Do you think something can be improved here?
Vladimir Kondratyev
Posts: 1624
Joined: Tue Aug 10, 2004 7:52 pm

Post by Vladimir Kondratyev »

Do you think something can be improved here?
retained size is a complex magnitude which reflects dependencies between application's subsystems. I don't see how it could be "improved". If some object has small retained size it just means that the object is not "important" from garbage collector's point of view. Could you suggest other magnitude which will reflect memory distribution and "importance" of each object?

BTW, please just try to use retained size instead of considering it useless :)
vgritsenko
Posts: 26
Joined: Mon Jan 24, 2005 7:29 pm

Post by vgritsenko »

Vladimir Kondratyev wrote:
Do you think something can be improved here?
retained size is a complex magnitude which reflects dependencies between application's subsystems. I don't see how it could be "improved".
What I can suggest is when class gets expanded (SuperRoot from example below), and its retained size does not add up (Retained(SuperRoot) > Shallow(SuperRoot) + Retained(Root1) + Retained(Root2)), add an extra line saying something to the effect "... and in addition to all members listed above, this class also retains XXX objects, YYY bytes through multiple paths to those objects. Cliclk F4 to view them".

BTW, please just try to use retained size instead of considering it useless :)
I do! I just had a little problem finding where 200Mb went which are not retained by any of the class members... :wink:
Post Reply