8000 [Fix #114] Add leak suspect retained heap top consumers by kgibm · Pull Request #115 · eclipse-mat/mat · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[Fix #114] Add leak suspect retained heap top consumers #115

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

kgibm
Copy link
Member
@kgibm kgibm commented Apr 9, 2025

As per #114, add a new second sentence (in bold below) that lists up to the top 3 consumers of the suspect's retained heap; for example:

The class com.example.AllocateObject, loaded by swat#swat-war.war, occupies 187.01 MB (76.19%) bytes. Its minimum retained heap is consumed by byte[] (187 instances totaling 187.00 MB), java.lang.reflect.Field (16 instances totaling 1.00 KB), and java.lang.Object[] (1 instance totaling 984 B). The memory is accumulated in one instance of java.lang.Object[], loaded by com.ibm.oti.vm.BootstrapClassLoader @ 0xf0030fe8, which occupies 187.00 MB (76.19%) bytes.

I wrestled with whether to use snapshot.getMinRetainedSet or snapshot.getRetainedSet. I ended up going with the former (and putting "minimum retained heap" in the message) because the leak suspects report can already run a bit long and I think the goal in the summary is just to get out quick first pass useful information rather than super precise information.

Also added an optional -Dorg.eclipse.mat.inspections.LeakHunterQuery.keywords=false JVM argument to hide the keywords section. There was some discussion on a bug or mailing list about this some years ago and the decision was to not change the default behavior, but I'd like to override this for our IBM Support servers as it causes some confusion.

Also added the option to specify an explicit BytesDisplay for BytesFormat in case someone ever wants to explicitly show a value as B/KB/MB/GB/etc. I ended up deciding against using it to match the rest of the leak suspects report (using whatever is set as the preference), but I thought it was worth keeping in there in case it's useful in the future.

Signed-off-by: Kevin Grigorenko <kevin.grigorenko@us.ibm.com>
@kgibm
Copy link
Member Author
kgibm commented Apr 9, 2025

@jasonk000 or @krumts: if one of you can please review when you have a chance, thanks!

@jasonk000 jasonk000 self-requested a review May 13, 2025 17:16
Copy link
Contributor
@jasonk000 jasonk000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Directionally looks good, some changes required though.

Comment on lines 638 to 652
Long sumHeapSize = sumHeapSizes.get(name);
if (sumHeapSize == null)
{
sumHeapSize = 0L;
}
sumHeapSize += snapshot.getHeapSize(objectId);
sumHeapSizes.put(name, sumHeapSize);

Integer count = counts.get(name);
if (count == null)
{
count = 0;
}
count++;
counts.put(name, count);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could be simplified

IObject object = snapshot.getObject(objectId);
String name = snapshot.isClass(objectId)
    ? ((IClass) object).getName()
    : object.getClazz().getName();

sumHeapSizes.merge(name, snapshot.getHeapSize(objectId), Long::sum);
counts.merge(name, 1, Integer::sum);

StringBuilder result = new StringBuilder();
List<Entry<String, Long>> list = new ArrayList<>(sumHeapSizes.entrySet());
list.sort((e1, e2) -> e2.getValue().compareTo(e1.getValue()));
List<Entry<String, Long>> finalList = list.subList(0, Math.min(list.size(), topItems));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

8000 I think this might be a slow way to sort for large counts - not sure how significant, what about something like a PriorityQueue to do the top-N sort? Probably not a huge deal.

entry.getKey(), count, bytesFormatter.format(entry.getValue())));
}
}
return HTMLUtils.escapeText(result.toString());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we want all of this escaped, otherwise I see <..> etc in the output.

image

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. I added escaping to fix some tests (classes with < and > in them) but then I forgot to run it again visually to see this.

Signed-off-by: Kevin Grigorenko <kevin.grigorenko@us.ibm.com>
@kgibm kgibm requested a review from jasonk000 May 23, 2025 12:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0