Class unloading (Was: Heap fragmentation (Was: Debugging "Leaks" With Boehm-GC))

Mon Jan 30 16:57:00 GMT 2006

>>And then an extra question:
>>I notice that the "Complete collection"-time increases quite when I 
>>suddenly "activate" (addresses and use the classes) new parts of my 
>>application (as expected I guess). But when finished using 
>>that part and 
>>all instances "should" be GC'ed, the GC-time remains the same 
>>(high) value. Is it because I actually do have 
>>leftover-instances, or is it just the 
>>nature of the GC - "once seen, always being 'scanned'"?
>>It would be nice to be able to "unload" that part of the application 
>>again, winning costly GC time...

> The class itself will not normally be collected, and hence anything
> that's referenced from static fields will stick around. Other than
> that, things should usually be collected. (I'm hedging a bit here,
> since old pointers could be left in stack frames, and with 4MB or roots
> on a 32 bit machine, there is some probability of accidental
> references.)

What about the strategy I just saw being implemented in JamVM:
 JamVM now supports class garbage-collection and unloading. It is
 implemented according to the clarifications to the JLS. This states
 that a class may be unloaded if and only if its class loader is
 unreachable. As the loader is reachable while any classes defined
 by it are reachable, the class loader and all its classes will be
 collected together.
Since it's in the JLS it may be standard GCJ behaviour?
BR,
 Martin Egholm