harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Wed, 25 Oct 2006 14:49:58 GMT
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 <weldonwjw@gmail.com> wrote:
>
> On 10/24/06, Aleksey Ignatenko <aleksey.ignatenko@gmail.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message