The Shortest Root Paths dashlet calculates the path of referrers to heap roots on the reference graph or on the Keep Alive graph. Use this to analyze why an instance is not garbage collected.
By keep alive
To calculate the Path to Root by Keep Alive, follow the Keep Alive referrer instance in the Keep Alive graph, until you reach the heap root instance. In the Keep Alive graph, each instance has exactly one Keep Alive referrer. The Root Path by Keep Alive is quickly calculated, but does not always show the reference graph's direct references. However, it does provide a good overview of why an instance is kept alive. If you require direct references, use Follow References Direct.
The Direct Path to Root dashlet tracks the referrers on the reference graph, until they reach the heap root. Most instances have more than one path to the heap root. The example below describes these paths. The following figure illustrates the Path to Root Direct for the same instance as the Path to Root by Keep Alive shown. The instance MBeanServerImpl@61499 has two referrers that use two different paths to the heap root. In the Path to Root by Keep Alive shown, the record above the MBeanServerImpl is the <VMRoot> instance, because there is no instance above MBeanServerImpl that exclusively references it. See Keep Alive graph for more information. In contrast, the Path to Root Direct dashlet displays these direct referrers and the path to root that they spawn.
The Direct Path to Root dashlet does not show each path to root. If an instance has two referrers that lead to the heap root, but run over the same parent instance, only one path is shown to prevent numerous paths. Consider the following example:
The reference graph of this example leads to three Paths to Root for instance A. The first (blue) runs through A->B->I->J->K. The second (orange) runs through A->B->G->H->L. The third (green) runs through A->B->C->G->H->F. Additional paths must root through A->B->C->G->H->J->K and A->B->C->D->E->F. So why are those paths not shown? The path through H->J is not shown because there is already a path running through J and this path is shorter (5 vs. 7 records). The path through C->D is not shown because it runs over F, which is already contained in the green path of an equal length.
Modify the previous reference graph: The heap root directly references instance E. AppMon reported the following Direct Paths to Root for instance C:
Before the modification, there are three paths to root, as in instance A. After the modification, there is an additional path, C->D->E, because E has no other path to root.
The Direct Path to Root dashlet uses the icons below to visualize references between two instances or classes. The tooltip displays text for the references.
|Reference from an instance to another instance|
|Reference from a class to an instance (static)|
|Reference from an instance to a class object|
|System class root reference or a .NET finalizer reference|
|JNI Global reference, a JNI local reference or a .NET Handle reference|
|Reference that is not reachable from a heap root|
|Thread root reference|
|Root reference to an instance on the stack|
|Monitor root reference|
|Reference from an array to one of its elements|
Simulate reference removal
As described previously, the Direct Path to Root dashlet does not show every path to a root instance because in a real world heap this results in numerous paths. Use the Simulate Reference Removal > Remove selected Reference context menu, or the icon in the filter bar (Ctrl+F) to simulate a reference removal and recalculate the corresponding Direct Paths to Root again. Use this to verify that an instance is no longer reachable from a heap root if you remove a reference. Also, you can use this to remove references within a Root Path that are correct, until you find a suspicious reference.
To restore references, Use the Simulate Reference Removal > Restore all removed References context menu, or the same icon in the filter bar (Ctrl+F).