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: <45450269.4020503@sablevm.org>
Date: Sun, 29 Oct 2006 14:35:05 -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
References: <5836de490610240251p120dfa56x736fbb5eb1898aca@mail.gmail.com>
	 <ehv01n$4bi$1@sea.gmane.org>
	 <bc79dd600610280713q4858afd9idffd5cb25b743aed@mail.gmail.com>
	 <ei20m8$cq5$1@sea.gmane.org>
	 <12385bbd0610290613j143aa91co2b02e5d486a14211@mail.gmail.com>
	 <4544BD6E.70205@sablevm.org>
	 <12385bbd0610290923t60f63c9cr3ad01d132d4c3a13@mail.gmail.com>
	 <4544EBC0.1030606@sablevm.org> <4544EFB8.4060704@sablevm.org>
 <12385bbd0610291051l4a23f64h8f726e1103a4bc59@mail.gmail.com>
In-Reply-To: <12385bbd0610291051l4a23f64h8f726e1103a4bc59@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig13C989154EA7856BB1A6D856"

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

I don't know about drlvm, but SableVM does keep a reference (i.e. a
local native reference) in each method activation frame to either the
instance (in case of an instance method) or to the class object (in case
of a static method).  This is required for correctly (and efficiently)
implementing the "synchronized" method modifier.  Of course, one could
have distinct method activation records for synchronized vs
unsynchronized methods, yet, if you think about it, keeping identical
activation records give you, for almost free, the class/instance
survival you seek to prevent class unloading.

The class loader should be not be unloaded before 2 conditions are met:
1- No instances of any loaded class.
2- The ClassLoader "instance" has been garbage collected.

This means that, internally, there is a class loader structure which
maintains a "weak" global native reference to its ClassLoader instance.

Hoping this helps...  Any volunteer to try it in SableVM?  Much easier
than coding it in drlvm for doing some initial experimentation. ;-)

Etienne

Ivan Volosyuk wrote:
> I like your idea. We can skip counting on young generation.
> 
> Good, this approach doesn't force us to convert VTables to java objects.
> 
> There is one more thing to clarify. Having no objects in heap we can
> have running method in stack which holds classloader from unloading.
> How can we deal with that? Should we examine root-set when going to
> trigger deallocation?

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

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

iD8DBQFFRQJpjyrJi4rH84gRAvEXAJ4k9HW96DugrcAsmPNFGCrKQPzSwgCffTuu
JL9EvXRyPOKTsFMiGWF8Qlc=
=nS4e
-----END PGP SIGNATURE-----

--------------enig13C989154EA7856BB1A6D856--