harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Ignatenko" <aleksey.ignate...@gmail.com>
Subject Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Date Fri, 10 Nov 2006 03:41:30 GMT
 Actually there is one additional 4-th approach:

*Mark and scan based approach *wich I described in the first letter. Java
heap trace is performed by VM Core and GC is not affected at all.

So the list is:
1. vtable objects( Aleksey )
2. per heap space/generation boolean marker on the classloader instance(
Etienne )
3. class reachability marker byte in vtable (Robin )
4. Mark and scan based approach.

I agree that we need to structure all appraches somehow, like description
for every approach in wiki.

Aleksey.

On 11/10/06, Rana Dasgupta <rdasgupt@gmail.com> 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 <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