harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Tue, 24 Oct 2006 16:02:41 GMT
On the 0x20C day of Apache Harmony Aleksey Ignatenko wrote:
> Hello all!
> 
> 
> 
> As you probably know current version of harmony DRLVM has no class unloading
> support. This leads to the fact that some Java applications accumulate
> memory leaks leading to memory overflow and crashes.
> 
> In this message I would like to describe two approaches for class unloading
> in DRLVM and propose to implement one of them as basic. Pros and cons for
> both approaches are presented below. Lets name these approaches:
> 
>    1. Mark and scan based approach.
>    2. Automatic class unloading approach.

I am +1 to (2)=(Automatic class unloading approach). Do not like
stop-the-world. 

But it has 1 more "cons" -- JIT should change it's devirtualizer
accordingly to the VTable change. Doable, of course.

BTW, is it reasonable to "compress" or "enumerate" references to
j.l.Class in each object to reduce the footprint? How many classes are
alive in heavy-duty applications? not very much probably.

> *Current DRLVM implementation specifics.*
> 
> 
> 
> All Java.lang.Class (j.l.Class) and java.lang.Classloader (j.l.Classloader)
> instances are enumerated as strong roots inside VM, which leads to the state
> when all j.l.Class and j.l.Classloader instances are always reachable.
> 
> 
> 
> To unload class loader CL three conditions are to be fulfilled (*):
> 
>    1. j.l.Classloader instance of CL is unreachable.
>    2. Classes (j.l.Class instances) loaded by CL are unreachable.
>    3. No object of any class loaded by CL exists.
> 
> 
> 
> Here is brief description for the both approaches:
> 
> 
> 
> *Mark and scan based approach.*
> 
> Java heap trace is performed by VM Core at the beginning of stop-the-world.
> If some class loader and its classes are unreachable and there is no object
> of these classes, then exclude this class loader from enumeration to make GC
> collect it. After GC happens and appropriate j.l.Classloader instance is
> collected – remove native resources from C heap: class loader and all
> classes loaded by it, jitted code and so on. Corresponding Java objects
> should already be collected by GC at this moment.
> 
> Pros:
> 
> - Simplicity – requires only additional mark&scan functionality on VM side
> to detect classes for unloading + few changes in enumeration algorithm.
> 
> Cons:
> 
> - Requires additional GC/VM functionality to trace j.l.Class and
> j.l.Classloader instances from each object.
> 
> - Duplicates mark&scan functionality on VM side.
> 
> - Affects every plugged GC.
> 
> - "Stop-the-world" state of VM is required, i.e. all threads except the one
> performing unloading should be suspended.
> 
> - Possibly some additional limitations on new GCs.
> 
> 
> 
> *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.
>    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.

-- 
Egor Pasko, Intel Managed Runtime Division


Mime
View raw message