Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313475

Summary: New GC root types make Paths from GC roots and Dominator tree less expressive
Product: [Tools] MAT Reporter: Krum Tsvetkov <krum.tsvetkov>
Component: CoreAssignee: Project Inbox <mat.core-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: andrew_johnson, karasiuk, krum.tsvetkov, rstheo
Version: 1.1   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Krum Tsvetkov CLA 2010-05-19 03:43:09 EDT
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&
Comment 1 Randall Theobald CLA 2010-06-08 08:54:59 EDT
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.
Comment 2 Krum Tsvetkov CLA 2010-06-08 08:57:51 EDT
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.
Comment 3 Andrew Johnson CLA 2010-06-10 05:49:11 EDT
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.
Comment 4 Gary Karasiuk CLA 2010-06-10 07:17:02 EDT
(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.
Comment 5 Andrew Johnson CLA 2010-06-21 10:29:54 EDT
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.