harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Wed, 25 Oct 2006 14:28:27 GMT
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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message