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?<div>

<br></div><div><a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6254531">http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6254531</a><br><div><a href="http://www.jroller.com/tackline/entry/fixing_threadlocal">http://www.jroller.com/tackline/entry/fixing_threadlocal</a></div>

<div><br></div><div>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..!</div>

<div><br></div><div>As mentioned, this is a long shot, but aspects of the mentioned problem looked similar.</div><div><br></div><div>Endre.</div><div><br><div class="gmail_quote">On Fri, Jun 12, 2009 at 22:05, Jacob Kessler <span dir="ltr"><<a href="mailto:Jacob.Kessler@sun.com">Jacob.Kessler@sun.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I'm working on the GlassFish scripting project, trying to solve an issue<br>
with the PermGen around deploying and undeploying applications.<br>
<br>
We use an embedded JRuby interpreter to host each deployed Ruby<br>
application, and JRuby makes extensive use of JIT-ed classes to improve<br>
performance. A typical JRuby instance takes roughly 20MB of permgen.<br>
We'd like for that space to be reclaimed once the application is<br>
undeployed, since losing 20MB of permgen each time an application is<br>
deployed puts a fairly hard limit on the number of redeploys that the<br>
server can take before it has to be restarted.<br>
<br>
We started out using -XX:+UseConcMarkSweepGC and<br>
-XX:+CMSClassUnloadingEnabled, and with the aid of a memory analysis<br>
tool (YourKit), we confirmed that some classes were being unloaded (not<br>
a significant number, though), and we tracked down and fixed two things<br>
that were improperly holding references to the classloader that<br>
contained JRuby. After fixing those, though, we ended up in a situation<br>
where YourKit was reporting the classes as still in memory after a<br>
forced full collection, but as having no paths to the GC roots. This<br>
situation seemed able to persist indefinitely (so, beyond time for the<br>
finalizer queue to drain). Does anyone have any ideas on what might be<br>
preventing the classloader from collecting?<br>
<br>
I'm using<br>
$java -version<br>
java version "1.6.0_07"<br>
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)<br>
Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode)<br>
<br>
Thank you for any help with this.<br>
<br>
_______________________________________________<br>
hotspot-gc-use mailing list<br>
<a href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a><br>
<a href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>
</blockquote></div><br></div></div>