harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Date Thu, 09 Nov 2006 23:30:06 GMT
Identifying an end to end alogirithm is of course necessary, and the
discussions on the other thread are great. But what were we voting on here?
My understanding was that we were voting on the approach of using:

1. vtable objects( Aleksey )
2. per heap space/generation boolean marker on the classloader instance(
Etienne )
3. class reachability marker byte in vtable (Robin )

and not on three end-to-end algorithms since Robin's description was not
one. I am OK if we now want to cancel the vote, but next time we vote on a
technical issue it may be a good idea for the caller to summarize the
contending solutions on the thread and then call for the vote.

Thanks,
Rana

On 11/9/06, Weldon Washburn <weldonwjw@gmail.com > wrote:
>
> 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:
>
> 1)
> Cancel the current vote on design.
>
> 2)
> Someone put together a complete class unloading design based on
> Etienne/Robin's approach.  Include pseudo code and post to harmony-dev.
>
> 3)
> 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
> > DRLVM.
> >
> > 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
>
>

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