GC

[James Kevin Doyle]

> 
> > Because our object format is so different from that in kaffe, we are building
> > our own JVM
> 
> You mean that the layout of an object is radically different?  Why?  How?
> Something not in the general model of "some header fields common to
> all objects followed by the non-static fields of the object"?
> 
There's one part of your definition of a general model that ours does
not follow: our header fields are not common to *all* objects.  
We distinguish a few different types of objects, so that the simplest
and most common objects can have the smallest header possible, whereas others
have longer headers.  Specifically, array objects have an extra field
for their size, and finalizable objects (those with non-trivial finalize
methods, that is) have an extra field for linking onto finalize lists.
We use various bit encodings to be able to tell the difference.  

The fixed fields are the class word, and the lock/hash/forward field,
which crams all of these functions into one word.  In the normal case,
the LHF field carries a hash value.  An object that gets synchronized
on has a lock object attached, which then carries the hash value.  A
forwarded object has its lock object in its forwarded copy, and so
forth.  The idea of a completely multi-purpose header field is also
where our format differs.  In any case, the main goal is to minimize
per-object space in the common case.

It just seemed that plugging our objects into kaffe would require 
tweaking of just about every part of the code, and so we're building
from the ground up.  This also allows us to design things like
method invocation paths as tight as we want from the beginning.

> Of course the devil is the details, and the actual header fields
> (including the gcInfo structure) in Kaffe are way too many.  However,
> we are paring them down - I've recently sent Tim patches to remove
> 16 bytes from each object.  We can "easily" get rid of another 16 bytes
> by reming the lock data structures from Object, as discussed earlier
> in this list.
> 
> Your GC sounds cool, which is why I'd love to integrate it into Kaffe.
> 
Our GC doesn't absolutely require our object format, of course; we
are trying to keep the GC toolkit as independent as possible.  In fact,
as far as the actual GC tools care, the only thing necessary from objects
is the ability to tell their size, to copy them from place to place,
to tell whether they've been forwarded, and to install a forwarding pointer.

The rest of the interface consists of the GC being able to ask the 
language to iterate through heap-external pointers (in the stack),
heap-internal pointers (write barriers and remembered inter-generational
pointers), and object-field pointers (requiring interpretation of the object
fields).  There are also lots of hooks for synchronizing between phases
for when multiple threads are involved.  

> 	--Per Bothner
> Cygnus Solutions     bothner at cygnus.com     http://www.cygnus.com/~bothner
> 

I'm glad our ideas (and the part of them achieved so far) impress!

Jim Doyle
jdoyle at cs.umass.edu