Classes not unloading correctly?

[Jacob Kessler]

While I don't think that I can check the behavior with -client (no easy 
access to 32-bit machines), allowing it to run with the permgen settings 
recommended in the bug report did allow class unloading to happen, which 
makes a strong argument for that being the issue. I'd be interested in 
trying the tentative fix out to see if that fixes things.

Y. Srinivas Ramakrishna wrote:
> Hi Jacob -- could you check if the same behaviour obtains with the 
> -client JIT-compiler as
> well. It is possible that this is related to 4957990. I'll contact you 
> off-line with
> a JVM that has a tentative fix for that bug to see if it makes any 
> difference to this
> problem.
>
> -- ramki
>
> Jacob Kessler 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
>>   
>