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: <455359C2.6070407@sablevm.org>
Date: Thu, 09 Nov 2006 11:39:30 -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>
 <eivjo5$cut$1@sea.gmane.org> <45535741.2080207@sablevm.org>
In-Reply-To: <45535741.2080207@sablevm.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigD7433FBA9E5992E41BCD842C"

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

Etienne Gagnon wrote:
> Salikh Zakirov wrote:
> 
>>I have another concern though: 
>>just before starting "final unloading" collection, we scan vtable marks and identify
>>the candidates for unloading. During the "final unloading" collection, the
>>candidate classloader roots are reported as week. At the end of the trace,
>>we need to rescan vtable marks and "revive" the classloader which were found
>>in possession of live objects. This techniques is exactly the same as the one
>>used for object finalization. 
>>
>>However, in contrast with finalization, we will need to repeat reviving
>>classloaders which have non-0 vtable marks until the process converges, and no
>>new classloaders are revived. (* in finalization, both dead and live objects in finalization
>>queue are revived, and thus the revival converges in just 1 step *).

In case you chose the finalization-like + revival way, then I don't see
any significant performance hit of multiple-step convergence!  For one
thing, you'll probably agree with me that it is quite unlikely to take
more than 1 step to converge in most cases, and the additional work in
the other cases is still quite insignificant relative to the remaining
collection work!

Etienne

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

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

iD8DBQFFU1nDjyrJi4rH84gRAlAmAJ4gKYhGlPBygx6Oo2f6jLkZJ+CpNQCfcJlq
pLEM5DtbT3yRzIEyGQYH5Hk=
=fkMf
-----END PGP SIGNATURE-----

--------------enigD7433FBA9E5992E41BCD842C--