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 - tested one approach
Date Thu, 09 Nov 2006 05:48:57 GMT
I was making it more complex than it needs...

Here's an improvement...

1- During normal operation, the VM keeps hard references to all class
loader instances.  [This prevents any premature class loader death].

2- At the start of an epoch (or just before), all vtable bits (or byte
or word) are cleared. [From now on, I will use the "bit" terminology for
simplicity.  The bit may reside in an otherwise unused byte or even
word, for efficiency purpose].

3- The end of an epoch happens "no sooner" than when all generations /
heap parts have been collected at least once since the epoch start.
[One can cheat and visit objects of uncollected parts/generations to
mark their vtables].

4- An "old generation" collection is chosen as the end of an epoch.
This is "end of epoch collection".  [As class loaders/classes are likely
to have moved to older generations, there's no point trying to kill them
in young collections].

5- Just before starting the "end of epoch collection", all the
class-loader vtable lists are visited (and bits are cleared in prevision
of the next epoch).  All vm references to [candidate] class loaders with
no surviving objects (nor active methods) (e.g. no vtable bit set) are
made "weak".

6- The "end of epoch collection" is launched.

7- There's actually no need for "rescuing" class loaders.  The vm
reference to any surviving [candidate] class loader is made hard again.
   Interesting fact: other candidate class loaders cannot have any
instance (nor any active method) as GC doesn't create instances nor
method calls.  So, there's no need for a rescuing dance!  The list of
dying class loaders can be used for freeing related native resources.

IMO: simple, clean, efficient...

Etienne

Etienne Gagnon wrote:
>  If it does, then can somebody explain to me what's wrong with
>  my proposal of setting, in normal operation, a "hard" reference to
>  class loader objects, and then temporarily using weak, rescuable
>  reference to enable class loader collection?  I don't see a performance
>  hog there.  Rescuing a few class loaders (if any) and their related
>  classes once per epoch shouldn't cost much!  I have yet to see a
>  convincing explanation of how continuous collection of "object-vtables"
>  would be more efficient...
> 
>  Really, even with Robin's proposal, this would work.  If a class loader
>  gets into an unloadable state, then most likely, the class loader and
>  all classes it has loaded will have migrated to an old generation.  So,
>  as long as we set then end of a class unloading epoch at an old
>  generation collection, then we can simply "weaken" the class loader
>  reference during collection (only when the bit of all related vtables
>  are unset), then apply the finalization-like rescue dance to class
>  loaders.
> 
>  [*]This wouldn't affect any other operation, during other GC cycles, as
>  Robin's unconditional bit/byte/word vtable write only serves to tell us
>  whether a class loader has had living instances of its classes during
>  the epoch.

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