Frank Kieviet : Weblog

Frank Kieviet

« Using Resource Adapt... | Main | JavaOne 2007 »

Wednesday May 02, 2007

JavaOne / memory leaks revisited...

Memory leaks in print

A few months ago, Gregg Sporar together with A. Sundararajan started an article on memory leaks in the magazine Software Test & Performance. While writing that, he stumbled upon my blog and decided to cover the "java.lang.OutOfMemoryError: PermGen space" exception too. I offered to collaborate on the article. The article eventually grew so much it was split in two. Part one was published a month ago. Yesterday, part two was published.

Memory leaks at JavaOne

Edward Chou submitted a proposal for a BOF at JavaOne 2007. He and I will be presenting a BOF on the "java.lang.OutOfMemoryError: PermGen space" exception. I'll try to record the session with my MP3 player and post it on my blog.

In preparation for our presentation, we've been looking at some real-life examples of permgen memory leaks. We took a few memory dumps that came from actual customers in actual production environments. We discovered a few more improvements we could make to jhat: it was already fairly simple to track the leaks with jhat; with these changes it becomes really simple. We were actually quite surprised how simple. More on that in a future entry, either on my blog or on Edward's.

More at JavaOne

Speaking about JavaOne... I have my hands full. Next to the memory leaks BOF, I'm also presenting a BOF on JBI ("How to develop JBI components") and I'll be co-presenting another BOF on "EE and JBI."

Posted at 09:56PM May 02, 2007 by Frank Kieviet in Sun | Comments[11]
Permalink: http://blogs.sun.com/fkieviet/entry/javaone_memory_leaks_revisited

Comments:

Hi, You might be interested in the new SAP Memory Analyzer tool. For details check https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/6433 We easily found classloader leaks with this tool. There's also a session about this tool at JavaOne (TS-21935). Regards, Markus

Posted by Markus Kohler on May 04, 2007 at 12:14 AM PDT #

I attended a session about the SAP Memory Analyzer at the german JAX conference and was very impressed. The tool is on the same DVD as the SAP J2EE environment, but it can be installed using a separate installer binary. Regards, Michael

Posted by Michael Bartmann on May 04, 2007 at 12:06 PM PDT #

Hi Michael, I'm glad to hear that you liked the tool. This is only the first version. The next version, will be *much* better. By the way,the same DVD will be available at JavaOne. Regards, Markus

Posted by Markus Kohler on May 05, 2007 at 04:03 AM PDT #

Hi Markus, will I need to attend yet another conference to get the next version, or is there an url to watch? Regards, Michael.

Posted by Michael Bartmann on May 05, 2007 at 10:46 AM PDT #

Hi Michael, Watch my weblog http://https//www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/6389 :) The next release should come out in summer. Regards, Markus

Posted by Markus Kohler on May 05, 2007 at 12:13 PM PDT #

Hi Markus, I just tried SAP Memory Analyzer tool from the JavaOne DVD, and I have to say I am pretty impressed with it. Very nice UI, and performance is great also. It also works well to find Classloader leaks, although I did find a bug with tool. When I try to trace paths from GC roots to an object without weak and soft reference, it still returns results that include ThreadLocal$ThreadLocalMap$Entry as a node in the path, however this inner class extends from WeakReference, so it should not be included. Other than that, I have no complaints.

Posted by Edward Chou on May 15, 2007 at 05:45 PM PDT #

Hi Edward, Thanks for your positive feedback :) We will try to verify that bug. In case you have a simple test case for it, please let my know. e-mail to "my first name dot my last name at gmail dot com" Regards, Markus

Posted by Markus Kohler on May 22, 2007 at 11:53 AM PDT #

Hi Edward, Only paths through the referent field will be avoided. Is the one you see through this field or through another one (e.g. value)? Regards, Krum

Posted by Krum on May 23, 2007 at 06:54 AM PDT #

Hi Krum, the path is through a ThreadLocal variable. See the screenshot of the path.

Posted by Edward Chou on May 23, 2007 at 10:33 PM PDT #

Hi Edward, the ThreadLocal$ThreadLocalMap$Entry is itself a WeakReference, but this alone is not all that matters to the JVM and its reference handling during the GC. Only the referent field (within WeakReference) is handled specifically, therefore the MemoryAnalyzer sees the object hold through the field value as strong reference, just as the JVM/GC would see it as a strong reference. This might irritate you as the value will be expunged by the data structure (important: by the data structure, not the GC) when it detects the clearing of the referent, but it is correct behaviour and has already proven to be important as e.g. with WeakHashMaps which become memory leaks if they are not accessed after the referents got cleared. The problem is that the data structure itself takes care for its data hold through the field value, not the JVM/GC and it does so only on access within its own code. Regards, Vedran

Posted by Vedran Lerenc on June 04, 2007 at 04:15 AM PDT #

Hi Vedran, I went back to look at the JDK source code for ThreadLocal, and you are correct regarding the "referent" field. The constructor of ThreadLocal$ThreadLocalMap$Entry calls "super(k)", so only the ThreadLocal instance if weak-referenced, and not the target object. My mistake, and thanks for the clarification, :-)

Posted by Edward Chou on June 07, 2007 at 02:56 PM PDT #

Sun	Mon	Tue	Wed	Thu	Fri	Sat
« November 2009
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Today

Frank Kieviet

Memory leaks in print

Memory leaks at JavaOne

More at JavaOne

Search this blog

Links

Weblog menu

Feeds

Who's reading this?