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] Class unloading support
Date Sun, 29 Oct 2006 19:35:05 GMT
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/

Mime
View raw message