geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Collins <>
Subject RE: Starting Geronimo with More PermGen
Date Tue, 15 Sep 2009 14:16:04 GMT
This permgen issue is not just a problem with Geronimo.  Apache Tomcat (6 and 5) has the same
issues with the permgen and continuous build integration.  

When deploying to Geronimo, we first undeploy the application then redeploy.  When we deploy
to Apache Tomcat, we do not do an undeploy.  Same results.

Russell Collins
Sr. Software Engineer
McLane Advanced Technology

"Do or do not, there is no try." - Yoda

-----Original Message-----
From: Quintin Beukes [] 
Sent: Monday, September 14, 2009 3:43 PM
Subject: Re: Starting Geronimo with More PermGen

Phew. I can actually imagine ThreadLocals being a hassle in a
multithreaded system regarding these leaks, as you can't really "check
the value" of the "variable". Especially when the same thread type
might behave differently at times.


On Mon, Sep 14, 2009 at 9:07 PM, Kevan Miller <> wrote:
> On Sep 14, 2009, at 1:29 PM, Quintin Beukes wrote:
>> 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?
> That's pretty much it. All it takes is a strong reference to any application
> object (object instance, class, etc). This reference will prevent the
> ClassLoader from being GC'ed. And this in turn will prevent all of the
> Classes loaded by the ClassLoader from being GC'ed. These strong references
> can come from ThreadLocals, statics, non-static references, or even stack
> references.
> Once you've generated a .hprof file, using post-mortem analysis, you can
> identify the causes of the memory leaks...
> --kevan

Quintin Beukes

View raw message