Bug 297052 - HTML tree reports are not expanded for leak suspects
Summary: HTML tree reports are not expanded for leak suspects
Status: RESOLVED FIXED
Alias: None
Product: MAT
Classification: Tools
Component: Core (show other bugs)
Version: 0.8   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 1.10.0   Edit
Assignee: Andrew Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 296826
  Show dependency tree
 
Reported: 2009-12-07 04:53 EST by Andrew Johnson CLA
Modified: 2020-03-05 08:19 EST (History)
1 user (show)

See Also:


Attachments
Expands a tree in the HTML report (2.25 KB, patch)
2009-12-15 12:11 EST, Andrew Johnson CLA
no flags Details | Diff
Example of unexpanded reference pattern (27.68 KB, image/png)
2020-02-22 07:18 EST, Andrew Johnson CLA
no flags Details
Example 1 (62.47 KB, image/png)
2020-02-22 08:44 EST, Andrew Johnson CLA
no flags Details
Example 2 (66.78 KB, image/png)
2020-02-22 08:46 EST, Andrew Johnson CLA
no flags Details
Example 2 (62.60 KB, image/png)
2020-02-22 08:53 EST, Andrew Johnson CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Johnson CLA 2009-12-07 04:53:54 EST
The leak suspects report can generate a tree view of paths to GC roots. Sometimes this is not expanded which means the stand-alone report is not very useful.

From my initial inspection of the code it seems that ISelectionProvider.EMPTY is used which returns false from isExpanded(Object row);

Example:

Reference Pattern
Class Name Shallow Heap Retained Heap Percentage 
class com.ibm.p8.library.standard.xapic.XAPICClass @ 0x491dbe58 64 2,557 0.01%
Comment 1 Andrew Johnson CLA 2009-12-15 12:11:39 EST
Created attachment 154497 [details]
Expands a tree in the HTML report

This seems one way of solving the problem.

Is it the right way?
Comment 2 Krum Tsvetkov CLA 2009-12-16 03:12:10 EST
This way you expand the whole tree. I tried running the component report on WeahHashMap$Entry, using the leaking-loaders sample we used at JavaOne. There it found several hundred possible leaks, and the fully expanded tree was huge. 

To open just one or several paths one can pass the selected paths as the third parameter to MultiplePath2GCRootsQuery.create(). We use this in the leak hunter query. 
I guess finding the most common path beginning (i.e. the part of the reference chains through which most of the suspects are reached) and expanding only it could be be a good alternative to show at least the "bigger" problems. Or may be expanding down to the last element (the strongly referenced WeakHashMap$Entry key) but just for some entries.
Or a mixture of both - 1) find the groups which have common beginning and 2) show one full path for all of them?

About the "reference pattern" example you have given above - this appears if there are no common paths going through exactly the same objects, but if there are paths going through objects of the same class, e.g. first any instance of a thread, then an instance of a HashMap, etc...
There it is common to see just one or two entries.
Comment 3 Andrew Johnson CLA 2020-02-22 07:18:47 EST
Created attachment 281889 [details]
Example of unexpanded reference pattern
Comment 4 Andrew Johnson CLA 2020-02-22 08:40:20 EST
Looking at this again I see that my main concern was the 'Reference Pattern' for multiple instances
as leak suspects.

This just showed a tree of class names up to the point where the class name was responsible for 90% 
of the instances.

I think the tree should be a tree in the Merge Shortest Paths to GC Roots, grouped by class name.
That would show the number of items at each level.

Also the tree could be expanded until the number of items wasn't >= 80% of the previous level.
This would expand the tree without expanding it too much.

If no one class was responsible for 80% of the instances then we could still expand all the classes
at the base level.
Comment 5 Andrew Johnson CLA 2020-02-22 08:44:23 EST
Created attachment 281890 [details]
Example 1
Comment 6 Andrew Johnson CLA 2020-02-22 08:46:07 EST
Created attachment 281891 [details]
Example 2
Comment 7 Andrew Johnson CLA 2020-02-22 08:49:10 EST
Two examples of how it could work.
Note the expansion and the highlighting of nodes which are the end of paths (in this example 'org.eclipse.equinox.internal.p2.metadata.InstallableUnit' instances).
Is expansion at 80% the right number (90% did not expand this example properly).

Note the tree shows the number of objects (of that type at that level in the path) and the number of referenced suspect objects in the path.
Comment 8 Andrew Johnson CLA 2020-02-22 08:53:58 EST
Created attachment 281892 [details]
Example 2

replaces previous
Comment 9 Eclipse Genie CLA 2020-02-22 10:20:50 EST
New Gerrit change created: https://git.eclipse.org/r/158120
Comment 11 Eclipse Genie CLA 2020-02-22 12:42:00 EST
New Gerrit change created: https://git.eclipse.org/r/158127
Comment 13 Andrew Johnson CLA 2020-02-22 12:45:33 EST
Krum and Kevin,
I've added you to this defect so you can review the leak suspects report as this is a high profile report.

This change affects a suspect report for the case of multiple object instances. It adds a pie chart and a list if some of the instances
are large.
Also, if there is no accumulation point then it improves the reference pattern tree (and adds a reminder if there are more than
10000 paths than it is a 'Reference pattern for 10,000 randomly chosen instances').
Comment 14 Eclipse Genie CLA 2020-02-23 08:02:13 EST
New Gerrit change created: https://git.eclipse.org/r/158182
Comment 16 Andrew Johnson CLA 2020-03-05 08:19:22 EST
I'll mark this as complete for 1.10