[kaffe] Memory Management Subsystem

[Patrick Tullmann]

Hi Barry,

> I'm working with a research group at the University of North Texas
> and I've been tinkering around with Kaffe's gc/allocator. The main
> goal is to create a pluggable environment for the allocator and the
> gc so that we can collect data on the behavior of various
> gc/allocator algorithm combinations with ease.

Kaffe has a start at that in the interface in gc.h.  There is only one
implementation of the interface (in kaffe/kaffevm/mem/), but there is
at least an interface to the GC factored out.  Are you building on
that?  Or doing something at a lower level?

> Currently, however I am having difficulties just implementing a
> different allocator. Instead of allocating pages or multiple pages
> and then segregating allocation type, color, etc within them, I'm
> allocating on a per object basis and storing this information
> contiguous with the object itself.

This should work....  This sounds similar to how the Kaffe GC used to
work (circa v1.0.5, I think?).

> I have also removed the 'grey' list in the gc, since it serves no
> real purpose yet.

Are you sure about this?  During a GC how do you distinguish an object
you've already seen in the current GC, but not yet walked from an
object you've seen and walked?

> So far, I am able to compile and run small programs, but get a ton
> of errors when I try to run the GCTest regression test. 

Are you getting seg-faults, or null pointer exceptions, or what?  If
you're getting errors out of GCTest, which method (testObj,
testPrimArray, etc.)?  You might try GCTest with the thread count of
1, or a much smaller "block size".

Depending on much of the existing GC code is still around you may want
to turn on some of the debugging stuff (specifically GCDIAG, which
turns on a bunch of sanity checks).  

Most of the errors that GCTest.java catches in Java awill be a result
of re-using memory that isn't actually free.  That implies that you're
freeing used objects or not finishing a walk on a reached object to
its referents.

> I'm wondering if Kaffe is inherently dependent somehow on how the
> allocator is currently implemented, since I have only been looking
> at the memory management part.

It shouldn't be dependent on anything except the correctness of the
current allocator.  :)  (Not that the current collector is bug free or
anything, though.)

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann at cs.utah.edu
		   ${HOME} is where the .emacs is.