| Query on Heap Dump [message #8815] |
Mon, 23 February 2009 10:23  |
Eclipse User |
|
|
|
Hi All,
Analyzing heap dump to debug the memory issue using MAT tool and found one
leak suspect, which shows as
54 instances of "org.apache.tomcat.util.threads.ThreadWithAttributes",
loaded by "<system class loader>" occupy 1,204,864 (69.35%) bytes.
As the above one is system Class and classes under this are Java Native
class, GC is not able to clear the memory. It seems all the objects are
referencing to Root and some of the threads were blocked.
Is there any way to find what is the root cause of this and how to analyze
these kind of issues.
Thanks in advance,
|
|
|
|
| Re: Query on Heap Dump [message #9312 is a reply to message #8821] |
Thu, 05 March 2009 10:19  |
| Eclipse User |
|
|
|
Thanks for the response,
I did some analysis on Thread issue. Histogram shows that top most class
names are byte[] and char[] classes and I checked in byte[] and found out
some of the url's are still referring to tomcat native classes and they
are holding the Thread (checked with list of objects with outgoing
references), but actually from our code we are no way referencing to
these. Do u have any idea why this is happening.
Shallow Heap Retained Heap
[] char [8192] --- url 16,408 16,408
org.apache.tomcat.util.buf.B2CConverter @ 0x2ab562d4a8 56 24,968
org.apache.catalina.connector.Request @ 0x2ab5614c68
296 57,208
java.lang.Object[32] @ 0x2ab56ac898 280 280
org.apache.coyote.Request @ 0x2ab49e5018 264 8,752
org.apache.coyote.http11.Http11Processor @0x2ab5626a20 200 157,816
java.lang.Object[3] @0x2ab55eeb08 48 158,672
java.lang.Object[2] @ 0x2ab56310a8 40 158,744
org.apache.tomcat.util.threads.ThreadWithAttributes @
0x2ab44caee8 Thread 192 169,240
The path2gc shows that last object is holding the thread. Is there any
way to identify from which of classes we are referring to this.
Thank u,
|
|
|
| Re: Query on Heap Dump [message #9404 is a reply to message #9312] |
Tue, 10 March 2009 05:57 |
| Eclipse User |
|
|
|
Hi there,
I am not quite sure that I fully understand the problem. In principle, the
thread is a garbage collection root (GC Root). The thread is not garbage
collected even if there are no references to it because there is an
implicit usage by the Virtual Machine - the VM is currently running the
thread. Now, of course, the thread can reference variables which are
currently on the call stack.
Looking at your example, it looks like the thread is currently executing a
request. It has a request processor on the call stack which then points to
an URL. It is somehow what you would expect, isn't it?
However, I have to admit, the more GC roots come into play, the harder it
becomes to analyze. In the end, those are objects which the VM deems to be
reachable - a native (e.g. DLL) method, a thread, and things like that.
Andreas.
|
|
|
Powered by
FUDForum. Page generated in 0.04171 seconds
Home