-
Notifications
You must be signed in to change notification settings - Fork 3
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
Diff Heap Dumps #4
Comments
By Nathan Reynolds on Jul 17, 2009 14:05 For the algorithm, I believe these are the roots that should act as starting points as opposed to what is displayed in the GUI. HPROF_GC_ROOT_THREAD_OBJ |
By Andreas Buchen on Jul 20, 2009 14:45 Hi Nathan, thank you very much for your comments! We have a very similar algorithm as a prototype running. The algorithm is comparing the length of the "shortest path to GC roots", the types (classes), the attribute names, the position in the array. To differentiate the GC locals, we use
The results were sketchy (besides being slow) - about 1/5 of the objects could be found again. Erwin is currently working on some pieces which allow to plug-in different compare functionalities to MAT. This could be one of them.
That is a great idea - which could possibly also be used for better #toString representation. |
By Krum Tsvetkov on Dec 18, 2009 03:20 I have created bug 298078: Comparison Features in MAT |
By Andrew Johnson on Mar 02, 2020 16:14 I've just revisited this bug. I have a prototype which generates a comparison tree if one of the inputs is a tree. This wasn't as complicated as I thought - IResultTree and IResultTable are quite similar. Matching of objects is more difficult - the current comparison query didn't work well when there were duplicate keys. If the trees are from the same snapshot then matching by objectId is easy. java.lang.Thread @ 0xe0c2ac98 main Is a simple RegEx to remove sufficient? I don't think having a replacement is important as the matching of the key |
By Andrew Johnson on Mar 02, 2020 16:17 Created attachment 281983 screenshot.png |
Mar 06, 2020 12:56 New Gerrit change created: https://git.eclipse.org/r/158932 |
Mar 25, 2020 13:40 Gerrit change https://git.eclipse.org/r/158932 was merged to [master]. |
Oct 13, 2020 10:07 New Gerrit change created: https://git.eclipse.org/r/c/mat/org.eclipse.mat/+/170710 |
Oct 13, 2020 10:08 Gerrit change https://git.eclipse.org/r/c/mat/org.eclipse.mat/+/170710 was merged to [master]. |
Oct 18, 2020 09:44 New Gerrit change created: https://git.eclipse.org/r/c/mat/org.eclipse.mat/+/170909 |
Oct 18, 2020 09:45 Gerrit change https://git.eclipse.org/r/c/mat/org.eclipse.mat/+/170909 was merged to [master]. |
Oct 22, 2020 02:32 New Gerrit change created: https://git.eclipse.org/r/c/mat/org.eclipse.mat/+/171099 |
Oct 22, 2020 02:34 Gerrit change https://git.eclipse.org/r/c/mat/org.eclipse.mat/+/171099 was merged to [master]. |
By Andrew Johnson on Oct 01, 2023 13:02 https://git.eclipse.org/r/c/mat/org.eclipse.mat/+/204704/1\ Snapshot leak suspect by comparison - have link for dominator tree diffs actually go to a dominator tree. |
| --- | --- |
| Bugzilla Link | 283778 |
| Status | ASSIGNED |
| Importance | P3 enhancement |
| Reported | Jul 16, 2009 20:25 EDT |
| Modified | Oct 01, 2023 13:02 EDT |
| Version | 0.8 |
| Depends on | 298078 |
| See also | Gerrit change https://git.eclipse.org/r/158932, Git commit 5f7e344d, Gerrit change 170710, Git commit 6ed8a869, Gerrit change 170909, Git commit 36277239, Gerrit change 171099, Git commit 7fd03e48 |
| Reporter | Nathan Reynolds |
Description
Diff'ing heap dumps is an extremely valuable ability. However, not many know how to diff two heap dumps when there is no common way to link two different objects together. Here is an algorithm which works fairly well. Please implement it soon. This is a much needed feature.
The user can then start expanding nodes into the tree to see where an object in one heap dump is holding onto more objects in another heap dump. This is where the leak is occurring. The user then has to figure out why the leaked objects are being left in their "parent" object... which is beyond the scope of a memory analyzer.
In the first phase, get the above working. In the second phase, we have to deal with collections. Collections are difficult because every child variable is the same.
When the algorithm hits a collection, it first has to use the type (class name) of the children objects for starters. For some uses of collections, this splits the children into several sets. For most uses of collections, all the children are of the exact same type so this doesn't help.
The next thing it should do depends upon the collection.
Lists - use the index of the element as a guide.
Maps - use the key to match like elements.
Sets - no ideas on this one. Good luck.
Some objects overload equals() and hashCode(). It would be helpful if the user could supply the jar file where the class is located. MAT could then load the class, create instances of the objects and force the member variables to be the values taken from the heap dump. The equals() and hashCode() operators will hopefully work and the objects can be paired.
A good heuristic would be to examine the member variables that are fundamental data types (e.g. char, boolean, byte, short, int, long) and Strings. The objects that are most similar should be paired.
In the GUI, allow the user to change the pairings as they see fit.
The text was updated successfully, but these errors were encountered: