GC

[James Kevin Doyle]

> 
> > 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.  
> 
> You must have *some* common fields, unless you classify the different
> kinds of header by address (e.g. page number).
> 
Right, I think I mentioned this in the previous email: the common fields
are a class pointer and the lock/hash/forward multi purpose field.
My point was simply that our headers are less straightforward and 
somewhat hacked for efficiency, so there tends to be a layer of
macros between the object structure and code that accesses the object.
Changing an existing interpreter at that level seemed to us to be
more difficult than writing our own.

> I think the biggest issue is you are using a copying collector,
> whereas Kaffe has non-copying conservative collector.  Using a
> copying collector would surely require many changes to Kaffe.
> And it might also make it difficult to use Gcc to compiled Java,
> though of course there is historical precedence for adding
> support for a copying collector to Gcc (your group's Modula-3).
> 
Certainly, all assumptions of stable object addresses have to go out
the window.  (Using object addresses for hash codes, e.g., or
keeping tables of objects by address.)  As for using Gcc to compile
Java, is your plan to use Gcc to produce *class files*?  Or *native code*, 
using the Kaffe JIT engine as a start?  I'd agree that augmenting Gcc
to include support for our collector in native-compiled code might
require significant change.  (I'm not incredibly familiar with our
Modula-3 collector work, though.  Most of my background has been with
the Smalltalk collector work, which of course is interpreted, hence
my interest in JVMs.)

> The jury seems to be out on whether the extra complication and
> overheads of a copying collector are justified by improved
> performance.  I tend to be skeptical.  But I would still love to
> study your code and algorithms, since I am sure there are ideas that
> would be valuable for Kaffe.  

One of the reasons we feel copying collection is a good fit for Java
is that it goes well with multi-threaded systems.  The work that
blocks mutators--allocation--is as quick as possible.  The heavy work,
copying the objects, can be pushed off on other threads that work at
the same time as the mutators.  (Our intention is to develop
asynchronous incremental collection, like the Nettles & O'Toole
model.)  I'll certainly let you know when we have a stable JVM and GC
that we would actually want someone to look at.  :) Our goal is to
have most of the features we want (multi-threading, JIT compiling, MOS
collection) by the summer.

Jim Doyle
jdoyle at cs.umass.edu