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] vote on class unloading design (was Class unloading support - tested one approach)
Date Thu, 09 Nov 2006 22:07:12 GMT
It looks like I called for a vote too soon.  The continuing discussion on
class unloading design is uncovering many important issues.  This is
excellent as it is much better to deal with design issues at this stage
rather than during implementation.

I propose the following:

Cancel the current vote on design.

Someone put together a complete class unloading design based on
Etienne/Robin's approach.  Include pseudo code and post to harmony-dev.

We call for a new vote once the comments on the documented design indicate
it is ready.

On 11/8/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> Pavel Pervov wrote:
> > Really BIG -1 from me.
> >
> > As Aleksey (Ignatenko) described in original thread, j/l/Class'es and
> > j/l/ClassLoader's are always available in rootset, so even if no objects
> > of a class exist, this class will be reachable.
> >
> > Actually, some sort of class unloading prototype exists in DRLVM code,
> > which
> > implements the scheme, which is very close to what is currently voted.
> It
> > was integrated with GC v4 and is not supported by other GCs. This
> prototype
> > traces up to class loader. Robin's approach is way faster then prorotype
> > is.
> >
> > Unfortunately, that approach requires up to 3 GC cycles to complete in
> > DRLVM.
> In a full-heap STW collector, my proposal would require 1 GC to collect
> unused classloaders.  In a generational STW collector, 1 full-heap GC,
> and would depend on the particular invariants enforced by an
> incremental/concurrent collector, but would be 1 complete "cycle" of any
> of the standard algorithms (I guess up to 3 GCs if the sweeps happened
> at the wrong places).
> > BTW, voted approach does not describe "proof-of-full-collection"
> algorithm
> > (at least I didn't find one). The only one I think of is
> > full-heap-collection, which _requires_ STW.
> My approach simply requires the underlying collector to have a notion
> that periodically it can say that 'every reachable object allocated
> since time 't' is now marked reachable.  If the class-unloader can
> ensure that one full epoch of this invariant has passed, then it can
> safely perform unloading.
> > Although "automatic anloading" brings some additional requirements for
> GC
> > (weak roots (references) support and pinned allocation), it is proven to
> > work (patch available) and, also, is the most natural algorithm for
> What is the run-time cost of it ?  And where is it described ?  I was
> only aware of Etienne's proposal as a full class-unloading scheme.
> > With the best regards,
> --
> Robin Garner
> Dept. of Computer Science
> Australian National University

Weldon Washburn
Intel Enterprise Solutions Software Division

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