geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DRob...@bfm.bm
Subject Re: OutOfMemoryException while redeploying WAR
Date Wed, 25 Apr 2007 15:19:15 GMT
You're correct. But there's been a lot of discussion surrounding this 
issue in the Tomcat forums. Maybe it's because the ClassLoaders don't get 
GC'ed correctly, but when Tomcat reloads an app, the class data seems to 
never get GC'ed. The same issue was found with Jetty, so it seems to be a 
VM issue. 


*************************************************************
Denis Robert
Senior Technical Architect
BF&M Insurance Group
Phone: (441) 298-0344
Email: drobert@bfm.bm
*************************************************************
This email and any files transmitted with it are
confidential and intended solely for the use of the
individual or entity to whom they are addressed.
If you have received this email in error please notify
the system manager.
*************************************************************



Kevan Miller <kevan.miller@gmail.com> 
04/25/2007 12:11 PM
Please respond to
user@geronimo.apache.org


To
user@geronimo.apache.org
cc

Subject
Re: OutOfMemoryException while redeploying WAR







On Apr 25, 2007, at 10:37 AM, DRobert@bfm.bm wrote:


It's related to the way Sun's JVM handles class data and internalized 
string. They make the assumption that you'd never want that information 
flushed from the VM, so they put that chunk of memory out of the reach of 
the garbage collector (i.e. "permanent generation"). Unfortunately, when 
you redeploy an application, you're really attempting to remove a bunch of 
classes and replace them with new ones. That simply doesn't work with 
Sun's VM; you only end up with both the old and the new classes in 
PermGen, even if the old class data is no longer useful or even 
accessible. 

There's no way around this one if you're using Sun's VM. Raising the 
amount of memory available for the permanent generation is really only a 
stop gap measure. If you feel you're going to redeploy your app very 
often, you should look into using another VM. I personally use JRockit for 
development (which is when I do most of my redeployment), even if I only 
run Sun's VM for staging and production servers (in order to take 
advantage of the deeper testing done on that VM). 

That's not accurate. PermGen memory *is* GC'ed. However, a Class can only 
be GC'ed when its ClassLoader has been GC'ed. In Geronimo, when you deploy 
an application, one (or more) ClassLoaders are created to load your 
application classes. When you undeploy your application, we free up 
references to that ClassLoader. Once the ClassLoader has been GC'ed, the 
application classes will be GC'ed from the PermGen space.

Denis describes the behavior of classes loaded by the System ClassLoader. 
Since the system ClassLoader will never be GC'ed, classes loaded by the 
System ClassLoader will never be GC'ed. That is not a problem for 
Geronimo, since application classes will never be loaded using the system 
ClassLoader...

--kevan



Mime
View raw message