geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quintin Beukes <>
Subject Re: Starting Geronimo with More PermGen
Date Mon, 14 Sep 2009 17:29:21 GMT
I assume that if you have a reference to one of these classes from
outside the application then it can prevent some classes to be GC'ed,
like a static reference you created in some global class? Is this
mostly the case, or is it more specialized?


On Mon, Sep 14, 2009 at 6:58 PM, Quintin Beukes <> wrote:
> I have read about this problem many times, and can never really
> understand that if the PermGen is GC'ed how a memory leak can occur
> that would cause a crash?
> After all, if all references to a Class is cleared it should be GC'ed, right?
> My understanding of how these memory leaks occur in these dynamically
> loading containers, like app servers (deployment), servlet containers
> (deployment), OSGi (bundles), etc. That means the same class is loaded
> many times, and sometimes anonymous/embedded classes in them, and
> dynamically generated classes (like proxies in Geronimo). Now, if you
> undeploy, won't this clear all references to these classes?
> Can you give me an example scenario of a real life memory leak which
> causes a leak and eventually PermGen OOME.
> Thanks,
> Q
> On Mon, Sep 14, 2009 at 5:06 PM, Kevan Miller <> wrote:
>> On Sep 14, 2009, at 10:07 AM, Quintin Beukes wrote:
>>> Doesn't Sun have a GC on the PermGen? Or is it just low priority,
>>> meaning this won't happen on production servers. Even in a the common
>>> production host you deploy a lot. They might be further apart, but
>>> they are many none the less. And these servers are usually solid,
>>> meaning they don't fall over. I will easily reach 10 deployments
>>> without a server restart.
>> Yes, PermGen is GC'ed. However, if there is a ClassLoader memory leak, then
>> a ClassLoader (and associated classes) can't be GC'ed, even though the
>> application has been undeployed.
>>> Though on my dev machine I have gone to about 20 deployments (around
>>> there - I just counted the log entries from server start while
>>> pressing page down the whole time and counted 18) before it gave a
>>> permgen. This was in a 2 hour period.
>>> If this is going to be a problem, is JRocket expensive?
>> I assume that JRockit stores class meta data in heap space. So, just means
>> you have more storage for your class meta data, rather than specialized
>> PermGen.
>> If you recreate your OOME PermGen with -XX:+HeapDumpOnOutOfMemoryError, we
>> can help diagnose your problem. One of these days, I'll write a blog on
>> this...
>> --kevan
> --
> Quintin Beukes

Quintin Beukes

View raw message