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: [EMAIL PROTECTED] ************************************************************* 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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] 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
