harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Astapchuk <alex.astapc...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Sat, 28 Oct 2006 07:15:02 GMT
Aleksey,

 >   1. Mark and scan based approach.
 >   2. Automatic class unloading approach.

In the #2, is there any chance for other components to be notified about 
   unloaded classes?

I can imagine many scenarios when a component needs to keep some data 
associated with the classes. If a class gets unloaded, then other 
components may need to clean up internal data as well.

The use cases I can think of are:
- a JIT that does whole program optimizations and associate some data 
with the classes - a profile data for example.

- a GC that again uses some class-related data. For example to improve 
locality of allocated objects basing on their types.

Perhaps there are other scenarios exist.

Or may be you have a proposal how to associate a resources with the 
classes in such cases?

-- 
Thanks,
   Alex


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.
> 
> 
> 
> *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.
> 




Mime
View raw message