On 10/24/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
*Automatic class unloading approach.* "Automatic class unloading" means that j.l.Classloader instance is unloaded automatically (w/o additional enumeration tricks or GC dependency) and after we detect that some class loader was unloaded we destroy its native resources. To do that we need to provide two conditions: 1. Introduce reference from object to its j.l.Class instance.
hmm... I think this means the object header size will increase by sizeof(reference_ptr). In addition to the cons listed below, the added ref ptr can cause cache pollution problems. From old studies adding a ref ptr to object header degraded overall performance about 3%. Maybe it makes sense to add a dummy slot in the existing object header layout to see what the footprint and speed impact will be on modern hardware. 2. Class registry - introduce references from j.l.Classes to its
defining j.l.Classloader and references from j.l.Classloader to j.l.Classes loaded by it (unloading is to be done for j.l.Classloaderand corresponding j.l.Classes at once). *Introduce reference from object to its j.l.Class instance.* DRLVM has definite implementation specifics. Object is described with native VTable structure, which has pointers to class and other related data. VTables can have different sizes according to object class specifics. The main idea of referencing j.l.Class from object is to make VTable a special Java object with reference to appropriate j.l.Class instance, but give it a regular object view from GC point of view. VTable pointer is located in object by zero offset and therefore can be simply considered as reference field. Thus we can implement j.l.Class instance tracing from object via VTable object. VTable object is considered to be pinned for simplification. In summary, having class registry and reference from object to its j.l.Classinstance we guarantee that some class loader CL can be unloaded only if three conditions are fulfilled described above (*). To find out when Java part of class loader was unloaded j.l.Classloader instance should be enumerated as weak root. When this root becomes equal to null – destroy native memory of appropriate class loader. Pros: - Unification of unloading approach – no additional requirements from GC. - Stop-the-world is not required. - GC handles VTables automatically as regular objects. Cons - Number of objects to be increased. - Memory footprint to be increased both for native and Java heaps (as VTable objects appear). *Conclusion. * I prefer automatic class unloading approach due to the described set of properties (see above). It is more flexible and perspective solution. Also JVM specification is mostly related to automatic class unloading approach while mark and scan based approach looks more like class unloading workaround. Please, do not hesitate to ask questions. Best regards, Aleksey Ignatenko, Intel Enterprise Solutions Software Division.
-- Weldon Washburn Intel Middleware Products Division
