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
