|
|
Re: How to find what is pinning the app classloader with MAT? [message #658983 is a reply to message #658678] |
Thu, 10 March 2011 15:48 |
Jon Seymour Messages: 5 Registered: March 2011 |
Junior Member |
|
|
Thanks for your help.
I tried the merge shortest path to GC roots with a package and wildcard and the -groupby FROM_OBJECTS_BY_CLASS. I also found the the -exclude option was very useful for excluding known pins like container provided caches.
Using MAT with heapdump and javacore files, I got what looked to be some promising leads, but I still had a 2000+ fanout from the top level to look at.
However, following one of these paths to the end I discovered for example, that there was an instance of com.ibm.rmi.transport.ReaderThread that was holding onto the app classloader via its contextClassLoader field. I managed (using some brutal hacking with netcat) to kill these threads hoping that this would release the classloader. No luck.
I also found a WeakHashMap in the java.lang.reflect.Proxy class which needs to be polled in order for its entries to be cleaned. However, causing this to happen didn't help.
However, I found that once I used a system dump, I got a much better result. When I did this, in addition to get field names etc, I got a much smaller fanout from the objects back to the roots [ 7 paths from the top-level ].
Furthermore, I discovered that the app classloader is also being pinned by hash table in the Apache commons logging implementation that is loaded by a system class loader, so this has given me something else to try.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03512 seconds