Sun > Forums > Isolating a PermGen error

[Peter B. Kessler]

Transferring this thread to hotspot-gc-use (as requested) to get advice 
from the experts on how to diagnose class loader problems.

I would start by adding

     -XX:+TraceClassLoading -XX:+TraceClassUnloading

to the command line and seeing if there were obvious classes that get 
loaded but not unloaded.

I don't know of any available statistics for the size of the interned 
String table.  But it is all open source, so you could add something. 
(Warning: That code is ugly, and it's among the oldest code in the VM.)

But likely other people have other, better ideas.

			... peter

> Subject: 	Re: Sun > Forums > Isolating a PermGen error
> Date: 	Thu, 02 Oct 2008 21:53:37 +0300
> From: 	Eyal Zfira <eyalzf at gmail.com>
> To:   	Peter B. Kessler <Peter.Kessler at Sun.COM>
> 
> The PermGen usage leap is caused by running a crystal report for the 1st 
> time. I noticed (by analyzing a heap dump) that there's a crystal thread 
> keeping some objects alive. My problem is that the PermGen usage keeps 
> raising with every report I generate (I have an open thread with Crystal 
> as well). I also noticed (using JConsole) that the loaded classes are 
> not kept still while the PermGen usage still rises. Is there a way to 
> find out whether it's interned strings or class problem? What is the 
> best way to "attack" a misused classloader problem?
> 
> Eyal
> 
> On Thu, Oct 2, 2008 at 9:09 PM, Peter B. Kessler <Peter.Kessler at sun.com 
> <mailto:Peter.Kessler at sun.com>> wrote:
> 
>     Thanks for the detailed log.
> 
>     You are, as you suspected, running out of permanent generation
>     space. That doesn't tell you why you are filling that space, but it
>     does tell you where to look: loaded classes and interned Strings.
> 
>     Except for the collection at 191.200, none of your collections frees
>     up any real space in the permanent generation, and that's after a
>     run up from ~40MB to 64MB from 183.652 to 190.850.  Can you
>     correlate that part of the run with things your application is
>     doing?  (That might also be a red herring.)
> 
>     If those objects are live (that is, if the collector is doing its
>     job, which I think it is), then you will have to figure out why they
>     are being retained.  That's real work.  If you were expecting
>     classes to be unloaded, you'll have to find why they are being
>     retained.  Usually that turns out to be because of the way you've
>     split class up among classloaders.  If you are interning that many
>     Strings, then you'll have to increase the size of the permanent
>     generation, or write your own equivalent of String.intern (think
>     WeakHashMap) so the unique copies of the Strings are kept in the
>     heap, not in the permanent generation.
> 
>                            ... peter
> 
>     Eyal Zfira wrote:
> 
>         Peter,
> 
>         First of all, thanks for the quick response.
>         You are more than welcome to publish this discussion (I'll
>         subscribe to the mailing list as well).
> 
>         Here is the more detailed GC log. I'm also monitoring the
>         application using JConsole and I keep seeing the PermGen memory
>         raising. ....

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use