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: <45534DF6.8070306@sablevm.org>
Date: Thu, 09 Nov 2006 10:49:10 -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] Class unloading support - tested one approach
References: <5836de490610240251p120dfa56x736fbb5eb1898aca@mail.gmail.com>
	 <4551B15B.2070101@anu.edu.au>
	 <5836de490611080250l6dfbd38cw8778f7a055373d82@mail.gmail.com>
	 <4551B83D.9020706@anu.edu.au>
 <4551CBDB.90004@anu.edu.au>	 <f944d83d0611082328s4d3fa75bm612e4de59719ac80@mail.gmail.com>
	 <f944d83d0611082342y1f45ba48lfcfaca99dbe70c4b@mail.gmail.com>
	 <f944d83d0611090022h3bcf1f6fudec3e27330771f19@mail.gmail.com>
	 <45531ED7.7030904@sablevm.org> <455324E1.2040301@anu.edu.au>
 <f944d83d0611090720q5719f9dcv50b2ac26c17aa8d4@mail.gmail.com>
In-Reply-To: <f944d83d0611090720q5719f9dcv50b2ac26c17aa8d4@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig5CE920B69F828B3BE6902A0B"

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

Alexey Varlamov wrote:
>> > My proposal already argued that vtable bit/byte/word marking is
>> > unnecessary for "nursery allocations".  You only need to mark the
>> vtable
>> > of objects that survive collection and pretenured objects.
> 
> 
> I may have missed it, but I only recall you argued that we just need
> to collect mature space for the *final unloading* as CL and classes
> are unlikely to die young, which I agree. But chances that a live
> object of a candidate class appeared in the nursery are higher.
> Otherwise I just do not grok how this algorithm can be proven for
> correctness.
> 

OK.  My latest proposal (a few messages ago) was assuming that the
nursery was empty when the "end of epoch collection" is launched.

If it is not, you can do 2 things:

a) do a minor collection to empty it, or

b) i  - use a finalization-like list of references to class loader
        objects
   ii - launch gc, which might mark a previously unmarked vtable
   iii- do a finalization-like rescuing for resuscitated class loaders

"b)" should really have a minimal performance impact.  As for its
"apparent complexity", I would say that this is a non-issue; similar
code must already exist in drlvm for implementing finalization.

Etienne

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

--------------enig5CE920B69F828B3BE6902A0B
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

iD8DBQFFU032jyrJi4rH84gRAjZfAJ9fKUz/Xjok1b/FfQRqcPYCJ3z/jQCeNOHK
YeEYGCgHZI40Pm8UPoNWygQ=
=+uwm
-----END PGP SIGNATURE-----

--------------enig5CE920B69F828B3BE6902A0B--