Classes not unloading correctly?
Endre Stølsvik
java at stolsvik.com
Sun Jun 14 00:49:39 UTC 2009
This might be totally off base, but this wouldn't by any chance be the
"classic" problem that e.g. Tomcat experiences when reloading a webapp,
where static ThreadLocals carrying a value whose class's classloader again
references the ThreadLocal - keeping the ClassLoader and its loaded classes
from being reclaimed?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6254531
http://www.jroller.com/tackline/entry/fixing_threadlocal
This problem would not have been there if the threadpool that served the
webapp wasn't recycled, but instead being dumped and recreated on reload.
I've been told that ephemerons could also have been used to solve the
problem, had they existed in java..!
As mentioned, this is a long shot, but aspects of the mentioned problem
looked similar.
Endre.
On Fri, Jun 12, 2009 at 22:05, Jacob Kessler <Jacob.Kessler at sun.com> wrote:
> I'm working on the GlassFish scripting project, trying to solve an issue
> with the PermGen around deploying and undeploying applications.
>
> We use an embedded JRuby interpreter to host each deployed Ruby
> application, and JRuby makes extensive use of JIT-ed classes to improve
> performance. A typical JRuby instance takes roughly 20MB of permgen.
> We'd like for that space to be reclaimed once the application is
> undeployed, since losing 20MB of permgen each time an application is
> deployed puts a fairly hard limit on the number of redeploys that the
> server can take before it has to be restarted.
>
> We started out using -XX:+UseConcMarkSweepGC and
> -XX:+CMSClassUnloadingEnabled, and with the aid of a memory analysis
> tool (YourKit), we confirmed that some classes were being unloaded (not
> a significant number, though), and we tracked down and fixed two things
> that were improperly holding references to the classloader that
> contained JRuby. After fixing those, though, we ended up in a situation
> where YourKit was reporting the classes as still in memory after a
> forced full collection, but as having no paths to the GC roots. This
> situation seemed able to persist indefinitely (so, beyond time for the
> finalizer queue to drain). Does anyone have any ideas on what might be
> preventing the classloader from collecting?
>
> I'm using
> $java -version
> java version "1.6.0_07"
> Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
> Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode)
>
> Thank you for any help with this.
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20090614/d45b6a22/attachment.htm>
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
More information about the hotspot-gc-dev
mailing list