Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)

[Geir Magnusson Jr.]

Yeah, I was going to point that out this morning, but decided to let it go.
There is really nothing technical to vote on here yet.  This is more of 
a "poll" to get discussion going about preferred approaches, and see if 
we can drive to consensus on how to move forward.  So for that, it was 
good that weldon kicked that off

So this is a good discussion, driving us towards an approach, but in the 
end, we'll really be choosing an implementation.

That said, anyone would be free to work on alternatives if they didn't 
agree with the rest of the group, but they would still need to 
demonstrate why that solution was better...

geir


Rana Dasgupta wrote:
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 <[EMAIL PROTECTED] > 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 < [EMAIL PROTECTED]> 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