Community
Participate
Working Groups
Often when doing memory analysis, I want to browse through many instances and quickly see what their 'shortest path to a GC root' is (I'll call this the instance's 'traceback'). This would need to be a separate view (visible concurrently with the main views) that would update based on the current selection in the main view. I see this as a peer (or part of) the Inspector view. The current option to merge/display paths to GC roots for an object provides this ability in a clunky way, especially for very deep reference chains. The traceback view I am requesting here would be a non-indented, fully-expanded display of the references leading back to the GC root, with the GC root at the top. This view could be configurable to skip weak/soft references, or to skip some object as specified by the user (i.e. find the next shortest path that doesn't include the specified object). The view should also be usable from a context menu stand-point (be able to right-click on an instance in the traceback and have the standard variety of options--including the option to ignore the instance in the traceback).
Thanks you for the idea, and sorry it took so long for the first reply. I agree such a view can be useful, and it will keep the user well informed about any object he is intersted in. I have however some concerns. Right now to calculate the paths, we do a breath-first-search starting from the object, until we reach a GC root. Depending on the depth of the path, the size and shape of the object graph, this can take a while. I am not sure if we can update the view on every user's click in a smooth and fast way. Adding some filters (e.g. skip weak or some other refs) slows things down even more. One alternative I am thinking about, would be to show the path up to the ROOT of the Dominator tree. This should be faster, as we have only one immediate dominator per object, i.e. no BFS is needed (and we have the dominator stored in an index). Indeed this will not answer the question "what is the shortest reference chain to my object", but it will answer something like "what is the keep-alive chain to my object". Do you think this will be a good enough compromise? I am also thinking about storing somehow the shortest path to each objects during parsing. If I manage to do something like this, then we can offer a solution closer to the request. However, I'm not sure yet if this one will succeed.
While I will say that something COULD be better than nothing, I will also be honest that the idea of using the dominator tree concerns me a bit. The fact that the dominator tree is a modified version of the reference graph--while helpful for determining retained heap values--could be very misleading and confusing for the type of analysis that I am proposing it for. As long as it was clearly label as coming from the dominator tree, and if there was no hope for getting a true traceback (shortest reference chain back to GC root), I would say that this is better than nothing. However, given that it IS possible, I think I would prefer the true traceback, even if it had a lag in updating that view (the previous references in the view should be deleted immediately upon selection change so that there can be no misreading it as it would otherwise contain old information, and there should be some indication that the view is updating, i.e. not just blank). Creating another index for something like this could be doable, but the footprint on disk is already quite large for all the existing indexes. If you allow me access to a prototype of just doing the BFS everytime, I can try it out and see if it is bearable using a large dump (I think 500 MB is my largest--heap size not core dump zip on disk size).
Created attachment 143627 [details] A patch adding a 'shortest path' tab to the object inspector
Created attachment 143628 [details] built plugin with the patch adding 'shortest path' tab in object inspector
Hello Randal, I made some changes, so that the required shortest path view appears as another tab in the object explorer. I haven’t submitted the changes in our repository, but I attach a patch and a built plugin for you. You can take the latest version from our download site and exchange one plugin with the one I attached. For now as I said the functionality is available as a separate tab in the object inspector. Therefore you can’t switch it on/off – it is always available. The path is a non-indented list of objects and the fieldnames. The object on the top is the object which was selected. You said you want the GC root on top, but for longer paths you will have to scroll to see the direct references to the object… It will be very helpful if you can try it out and give us your feedback. Some more notes – for the moment it is not possible to exclude some paths. The paths are calculated using the algorithm we had in place. But I am now sure it will be possible to store a path per object. If I implement this in a later moment, then the results will show up much faster. I’m looking forward to your comments. Krum
I got lucky and was able to give this a quick try. A couple things: (1) When switching between two objects, there is a delay (expected, but really not bad at all for my little dump). However, during that delay, the old contents of the shortest path tab are still there. These should be blanked out immediately on object selection change. Otherwise, it could be easy to glance at it while it's doing a long update and get the wrong data. (2) I would REALLY prefer the GC root at the top. For this type of analysis, at least in the products I analyze, the actual GC root (or very close to it) are normally the most interesting parts of the shortest path. Having to scroll down is fine (or arranging the tabs so that there is plenty of vertical space). One main reason why the root should be at the top is that when comparing various similar objects, the top lines shouldn't change if they have the same root (no matter what the object depth)--i.e. you can quickly see where the divergence is. If the root is at the bottom, then you only have similar lines if the object depths are equal. Again, I REALLY think that the GC root should be at the top. Or, at least make it configurable. Otherwise it is looking good. I like the addition of the reference name column. It would be nice if I could detach the tab and place it anywhere (not just under the inspector tab), but that is a minor grievance.
Thanks for the quick feedback! Based on it I think we should: 1) add a control to turn the direction of the path (GC roots on top or the Object on top). What is more convinient depends very much on the concrete use case 2) Create a separate view instead a tab in the object inspector. Thus it will be possible to show / hide the view and also move it wherever it fits. 3) clear the view when a new object is selected Unfortunately I won't be able to do this in the next 3-4 weeks. Hope this is fine. I'll deffinitely come back to the topic later.
This issue has been migrated to https://github.com/eclipse-mat/org.eclipse.mat/issues/1.
