harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Ignatenko" <aleksey.ignate...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Wed, 25 Oct 2006 04:32:19 GMT
Egor,
>But it has 1 more "cons" -- JIT should change it's devirtualizer
>accordingly to the VTable change. Doable, of course.
There is no need to change struct VTable structure - it could be simply
inlined in pinned VTable object + 1 additional reference field to j.l.Class.
So there won't be too much work to do on JIT side.

>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.
We are to trace j.l.Class from every object via VTable to detect if there is
any live object of that j.l.Class. This one of requirements of class
unloading.
As for footprint - there is already pointer to struct VTable in every
object, so changing this pointer to reference to VTable Object will have no
effect on footprint. Compressed VTable pointers will be changed to
compressed references. The only effect is that VTable object is a full Java
object and in its turn it is to have own VTable, so number of VTable objects
will encrease for every class. As Vtable is a small object footprint will
encrease only for tens of bytes for every loaded class, and as I know, there
are loaded several thousands classes on Eclipse startup, therefore footprint
increase is negligible.

Aleksey Ignatenko,
Intel Enterprise Solutions Software Division.

On 24 Oct 2006 23:02:41 +0700, Egor Pasko <egor.pasko@gmail.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message