Eclipse Community Forums: Memory Analyzer (MAT)

Help

Home

Home » Archived » Memory Analyzer (MAT) » Query on Heap Dump

Show: Today's Messages :: Show Polls :: Message Navigator

Query on Heap Dump [message #8815]

Mon, 23 February 2009 15:23

udaysankarp

Messages: 2
Registered: July 2009

Junior Member

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,

Report message to a moderator

Re: Query on Heap Dump [message #8821 is a reply to message #8815]

Thu, 26 February 2009 10:35

Andreas Buchen

Messages: 123
Registered: July 2009

Senior Member

> 54 instances of "org.apache.tomcat.util.threads.ThreadWithAttributes",
> loaded by "<system class loader>" occupy 1,204,864 (69.35%) bytes.

Mmmhh.... let me do some random rambling here. First of all, as you have a
lot of threads, it indicates heavy load on the system. On average, each
thread is using some 20K that do not look like a lot.

I'd look into the following: is there one thread using much more memory
than the others? Then go and have a look at the outgoing references.
Especially the ones marked as <Java Local>. Those are variables which are
currently on the call stack of the thread. They indicate what the thread
is currently doing.

Another approach is looking at the retained set of all of those threads
(available via context menu) and take a look at the objects. Many hash
maps? Objects staying around for too long? Huge arrays?

And finally, also take into consideration that the system just might need
resizing, i.e. more heap.

Sorry. I have no straight forward answer...

Andreas.

Report message to a moderator

Re: Query on Heap Dump [message #9312 is a reply to message #8821]

Thu, 05 March 2009 15:19

udaysankarp

Messages: 2
Registered: July 2009

Junior Member

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,

Report message to a moderator

Re: Query on Heap Dump [message #9404 is a reply to message #9312]

Tue, 10 March 2009 09:57

Andreas Buchen

Messages: 123
Registered: July 2009

Senior Member

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.

Report message to a moderator

Previous Topic:	Unreachable Objects
Next Topic:	Save value to file: support specific encoding

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 19:46:07 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter