harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Etienne Gagnon <egag...@sablevm.org>
Subject Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Date Fri, 10 Nov 2006 14:07:21 GMT
The http://wiki.apache.org/harmony/ClassUnloading wiki page is
"Immutable".  How can I contribute to it?

[Among other things, I'd like to add that the design can also
potentially apply to SableVM and , and make other suggestions / changes.]

Do I have to submit JIRA bugs?  If yes, how do I make the patches? (svn
diff?)

Thanks for helping me!
Etienne

Aleksey Ignatenko wrote:
> 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
>> >
>> >
>>
>>
> 

-- 
Etienne M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Mime
View raw message