Community
Participate
Working Groups
As discussed in the forum [1] there are certain GC root types which the Paths from GC roots query should ignore. An example of such root is UNFINALIZED. Having the query end the path at such object makes it difficult to see the "real" GC roots, e.g. the real reason for the object to be kept. We should define which GC root types can be ignored and try to change the implementation of the query. [1] http://www.eclipse.org/forums/index.php?t=msg&th=168323&start=0&
This issue is a major problem which has stopped me from using 1.0 entirely. I've been trying to use MAT 1.0 for the majority of my memory work, but it is giving me problems in how, I assume, it is creating the dominator tree. In 1.0, MANY, MANY more things appear to be their own GC root. If I load up the same dump in 0.8, I get much more useful information. How has the creation of the dominator tree/GC roots determination changed from 0.8 to 1.0? I'm finding that 1.0 is almost useless because of this issue.
I think both problems are related and we should have some discussion in this bug how to solve several problems - to get only the real GC roots as GC roots again - to attach some special semantic to certain objects (like the unfinalized...) - what are use cases where it is really necessary that the paths from GC roots go through the GC root nodes I am changing the short description of the bug accordingly.
DTFJ Roots of type UnfinalizedObject are not marked as roots because they are just weak roots. However, there is some code that if finalizable objects (object on the finalizer queue) are not found via DTFJ then they are created as roots by looking for objects with a finalize method where the objects are unreferenced. Some extra code also marked referenced objects which could be finalized later as Unfinalized. This created the spurious GC roots. The fix is to only mark those objects if the skipWeakRoots flag is false. We can consider whether to tag unfinalized objects or other weak roots in some other way which doesn't break paths to GC roots. Also having the boot loader as a source for the roots is confusing.
(In reply to comment #2) > - what are use cases where it is really necessary that the paths from GC roots > go through the GC root nodes Hi Krum, I use the tool for two main use cases (and they are strongly related) 1) Our product has hit an OOME, and I need to figure out the cause. 2) Our product is using more memory then we think it should for a particular scenario, and I want to understand how to use less memory. To me the most important function, is a way to understand what is keeping stuff in memory, so that I can make the right changes so that we use less memory. Any false hits, just make my task harder, and are a distraction.
I've stopped UnfinalizedObjects being roots (unless skipWeakRoots flag is false.) I've stopped the boot loader being a source for roots, except for system classes. If we need to mark objects as weak roots (e.g. if they are tagged, but not treated as roots), then that can be handled with another enhancement.
