-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Slow parsing due to huge ClassImpl.subClasses in GarbageCleaner #59
Comments
Yes, solution to use LinkedHashSet instead of ArrayList for |
looks related in #57 |
@turbanoff , thank you for the issue/analysis/fix. Are you able to share the heapdump or do any more analysis here? As we saw in #57, the patch to GarbageCleaner to use FJ pool seems to have triggered this. But the patch does not change the ClassImpl, which makes me wonder -- does the new |
Here the dump, which Eclipse MAT opens very slowly. Was able to create it with quite small program. |
@turbanoff thanks for the report, fix, and repro, I've put together patch in #63 , though I only addressed the first list/set, which led to a significant boost. Let me know if you disagree with it. |
I have a heap dump, which Eclipse MAT have troubles to open.

Thread dump always show this stack trace:
I was able to attach debugger.


Seems issue with huge lists, used by
org.eclipse.mat.parser.internal.GarbageCleaner
First one is -
org.eclipse.mat.parser.model.ClassImpl#subClasses
Second one is -
classes2remove
I think at least
org.eclipse.mat.parser.model.ClassImpl#subClasses
could be converted to HashSet/LinkedHashSet to makeClassImpl.removeSubClass
to be run in O(1).The text was updated successfully, but these errors were encountered: