gback at cs.utah.edu
Mon Feb 15 09:49:51 PST 1999
> I am thinking implementing memory defragmentation for kaffe, since kaffe
> seems not having this feature. Could anyone suggest a better way to do it,
> specially on updating memory address after moving blocks?
I assume you are talking about a mostly copying compacting collector,
is that correct?
The way to implement this is to write a replacement for the kaffevm/mem
subdirectory. You may be able to use or reuse all or parts of Jason's
recently implemented basic allocator.
Furthermore, take a look at kaffevm/gcFuncs.c kaffevm/gc.h. You will need
to extend the gc interface to communicate information about the locations
in which pointers to gcable objects are stored between the VM and gc subsystem.
While I haven't thought about a whole lot, it seems that one way of doing this
is to export the bitmaps that are internally used by gcFuncs.c & classMethod.c
in a clean way to the collector. This will cover the heap->heap references
in most ordinary Java objects. Study walkObject in gcFuncs.c.
As for objects of type Hjava_lang_Class*, the quickest way of handling those
may be to assume that they are not movable. Given their lifetime, it's likely
that this is an okay assumption. Keeping track of the locations in which
pointers to gcable Class objects are stored is probably more difficult.
Finally, be aware of the fact that a moving collector must properly
implement the System.identityHashcode() method.
If you have specific questions about the way in which Kaffe objects are
laid out, feel free to post it.
More information about the kaffe