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/
signature.asc
Description: OpenPGP digital signature