Archie, thanks for the info, the approach looks like the second one I suggested. We can take it at first.
Btw, there are some situations I am not sure if the approach you mentioned is possible. For example, we may want to reclaim also VM structures for strings that is not associated with a class loader, or to reclaim some jitted code buffers before the class loader is unloaded, or sometimes we want to put certain data/codes closely together for better cache/branch effects. Suggestions? Thanks, xiaofeng == Intel Managed Runtime Division On 9/8/05, Archie Cobbs <[EMAIL PROTECTED]> wrote: > Xiao-Feng Li wrote: > > They are basically two approaches to unload the classes, one is to > > encode the VM object similarly as App object with a header, then GC > > can treat them uniformly (almost); the other approach treats class > > unloading specially, which reclaims a class loader together with all > > its associated VM objects. The former approach can reclaim as more as > > possible VM objects (besides other benefits such as code placement) > > but requires more GC overhead, while the latter approach can reclaim a > > class loader related objects all together if they are arranged > > properly. > > You can get the benefits of both approaches using per-class loader > memory areas like SableVM and JCVM. Each class loader has it's own > stack of memory. All loader-related memory is allocated from that > stack (including possibly java.lang.Class objects). Then when you > unload the loader you free the entire stack at once. During GC you > treat a class loader's stack as a single giant object. For more info: > http://jcvm.sourceforge.net/share/jc/doc/jc.html#GC%20and%20Class%20Loaders > > Cheers, > -Archie > > __________________________________________________________________________ > Archie Cobbs * CTO, Awarix * http://www.awarix.com >
