Robin,
The basic difference of this with Etienne's method is that the flag is
on the vtable, instead of the CL instance. Do I understand correctly ? The
GC perf impact is therefore reduced because you need to lookup
object->vtable instead of object->class->CLinstancewhen tracing the heap.
The space overhead is correspondingly slightly higher. Also the GC impact
may look lower because there are a couple of pseudo GC cycles to reset the
vtables and sweep the vtables.
Thanks,
Rana
On 10/31/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
>
|