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 18:15:20 GMT
Wait a minute!  I missed something.  Actually, there is no need to track
allocations in the young generation!  Only survivals.  So, you apply the
boolean trick only for objects that survive the nursery collection.

So, there would be no bit overhead in objects, nor work overhead on
allocations.  Just a little overhead on moving objects across generations.

As for the class loader, there are many solutions; one is to maintain a
list of loaded classes with surviving objects.  Every time a class sets
one of its gc-area booleans to false (at the end of a gc cycle), it
checks whether all its other gc-area booleans are also false.  If yes,
it removes itself from the class-loader "loaded class with surviving
objects" list.  When this list becomes empty, the class loader can be
unloaded (as soon as it is not referenced elsewhere).

Making any sense?


Etienne Gagnon wrote:
> Ivan Volosyuk wrote:
>>If I understand you correctly, you suggest to increment
>>per-classloader object counter on allocation... It can be much
>>overhead with the solution, as most of the objects die young.
>>Do I miss something?
> No, I was thinking about a "per-class" counter.  Actually, a counter is
> not needed.  A simple boolean is suffucient (one boolean per gc
> generation in each class), so the cost would be a single inconditional
> memory write per object allocation.  I would think that this would be
> lost in the noize of object field "zero" initialization. No?
> Etienne

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

View raw message