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.
[#512] Retained size of object discrepancies
-
- Posts: 26
- Joined: Mon Jan 24, 2005 7:29 pm
-
- Posts: 26
- Joined: Mon Jan 24, 2005 7:29 pm
-
- Posts: 1626
- Joined: Tue Aug 10, 2004 7:52 pm
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:Any opinion on this one? Is it a problem or am I wrong?
Code: Select all
Root1 Root2
| |
| |
+---->Obj0<--+
|
v
Obj2 -> Obj3 -> Obj4 ->.....->Obj10000
Please try to read the bundled documentation which describes in detailes the nature of retained size.[/code]
-
- Posts: 26
- Joined: Mon Jan 24, 2005 7:29 pm
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:
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?
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
-
- Posts: 1626
- Joined: Tue Aug 10, 2004 7:52 pm
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?Do you think something can be improved here?
BTW, please just try to use retained size instead of considering it useless
-
- Posts: 26
- Joined: Mon Jan 24, 2005 7:29 pm
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".Vladimir Kondratyev wrote:retained size is a complex magnitude which reflects dependencies between application's subsystems. I don't see how it could be "improved".Do you think something can be improved here?
I do! I just had a little problem finding where 200Mb went which are not retained by any of the class members...BTW, please just try to use retained size instead of considering it useless