And yes, there will be reference to corresponding java/lang/Class in VTable object. Which means that j/l/Class will be reachable from any object of this class.
So, still no object size increase. :) Pavel. On 10/25/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
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
-- Pavel Pervov, Intel Enterprise Solutions Software Division
