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 - tested one approach
Date Wed, 01 Nov 2006 11:03:45 GMT
+1 for this approach. It will give us some kind of class unloading
without much performance impact on GC.
--
Ivan

On 11/1/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> Actually, just thinking about how I would implement this in JikesRVM, I
> would use the reachability based algorithm, but piggyback on the
> existing GC mechanisms:
>
> - Allocate a byte (or word) in each vtable for the purpose of tracking
> class reachability.
> - Periodically, at a time when no GC is running (even the most
> aggressive concurrent GC algorithms have these, I believe), zero this
> flag across all vtables.  This is the beginning of a class-unloading epoch.
> - During each GC, when the GC is fetching the GC map for an object,
> *unconditionally* write a value to the class reachability byte.  It may
> make sense for this byte to be in either the first cache-line of the
> vtable, or the cache line that points to the GC map - just make sure the
> mark operation doesn't in general fetch an additional cache line.
> - At a point in the sufficiently far future, when all reachable objects
> are known to have been traced by the GC, sweep the vtables and check the
> reachability of the classloaders.
>
> The features of this approach are:
>
> - Minimal additional work at GC time.  The additional write will cause
> some additional memory traffic, but a) it's to memory that is already
> guaranteed to be in L1 cache, and b) it's an unconditional independent
> write, and c) multiple writes to common classes will be absorbed by the
> write buffer.
>
> - Space cost of at most 1 word per vtable.
>
> - This works whether vtables are objects or VM structures
>
> - If the relationship between a class and a vtable is not 1:1, this only
> need affect the periodic sweep process, which should be infrequent and
> small compared to a GC.
>
> - shouldn't need a stop-the-world at any point.
>
> I've implemented and tested the GC-relevant part of this in JikesRVM,
> and the GC time overhead appears to be just under 1% in the MMTk
> MarkSweep collector.
>
> cheers,
> Robin
-- 
Ivan
Intel Enterprise Solutions Software Division

Mime
View raw message