harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Sun, 29 Oct 2006 18:51:22 GMT
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?
--
Ivan

On 10/29/06, Etienne Gagnon <egagnon@sablevm.org> wrote:
> 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
>
> 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/

Mime
View raw message