Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45548799.8090202@sablevm.org>
Date: Fri, 10 Nov 2006 09:07:21 -0500
From: Etienne Gagnon <egagnon@sablevm.org>
User-Agent: Debian Thunderbird 1.0.2 (X11/20060927)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] vote on class unloading design (was Class unloading
 support
 - tested one approach)
References: <4dd1f3f00611070932w103a6aadyf85436df89eaa60a@mail.gmail.com>
	 <9623c9a50611071513g4a4d222fn2c401a91f87bb0e8@mail.gmail.com>
	 <455113C5.8090308@sablevm.org>
	 <51d555c70611071524q175459a6mce3b4adc0203e50c@mail.gmail.com>
	 <9623c9a50611071555j7c10bbbt18699be5510efc7@mail.gmail.com>
	 <45515C06.3050204@anu.edu.au>
	 <e0f125db0611080136n47c446dcud127a101592a2c1f@mail.gmail.com>
	 <4551AF43.1020005@anu.edu.au>
	 <4dd1f3f00611091407j318c3c1dn8aba8835897738b1@mail.gmail.com>
	 <51d555c70611091530k18615e1x214beef36d1f0612@mail.gmail.com>
 <5836de490611091941j5ff3447ci5ecd007a7f8170c3@mail.gmail.com>
In-Reply-To: <5836de490611091941j5ff3447ci5ecd007a7f8170c3@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig78DC6312E02A07A929508AA1"

--------------enig78DC6312E02A07A929508AA1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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/

--------------enig78DC6312E02A07A929508AA1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFVIefjyrJi4rH84gRAuDzAKCABetBx02WvxuhgKUbbUhQrZMCBACeNml2
2jjsDKRBwHTHQA7d2M6m8Vs=
=DChH
-----END PGP SIGNATURE-----

--------------enig78DC6312E02A07A929508AA1--