Sun > Forums > Isolating a PermGen error
Peter B. Kessler
Peter.Kessler at Sun.COM
Thu Oct 2 12:05:47 PDT 2008
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
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.
> 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?
> 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:
> 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
More information about the hotspot-gc-dev