Ren-Song Ko wrote:

> 	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?

If you're looking for specific algorithms for operations like moving
blocks of memory, then I strongly recommend `Garbage Collection:
Algorithms for Automatic Dynamic Memory Management' by Jones and Lins
(1996).  It's my I Ching.


I'm still a weenie at programming, but I've had a Good Hard Think (tm)
about this and I still don't see any memory structure that'll work
better than the current system, which (as you know) dedicates each
memory block to a certain size of object.  (In that respect, it's
similar to the Boehm-Demers-Weiser collector; the book mentioned above
cites [Boehm and Weiser, 1988].)

Moreover, since we've got ambiguous pointers, we can't move an object
without tracing all pointers to it to make sure that none of them are
ambiguous.  The only sensible time to do this tracing is at GC-time,
so we may as well make a copying collector.  Yum.  :)

Bartlett's (1992) Mostly Copying collector would be good, except that
it assumes that only the roots are ambiguous and that all objects are
movable if not referenced from the roots.  Neither of these conditions
apply in Kaffe.  We've got ambiguous pointers in the JIT code (that
is, when I poke around in JIT code I find a lot of numbers
corresponding to addresses of CLASS objects), and we've got lots of
objects that can't be moved (GC_ALLOC_FIXED).  The problem needs more
study, but I suspect that a MC-based collector would keep unacceptable
amounts of tenured garbage, because it hangs onto whole blocks if
there any ambiguous pointers reference them.

Of course some defragmentation can be done with the current system,
but I don't see that that it would be particularly beneficial.
Implementing a clean, memory-efficient collector for Kaffe is going to
be a toothsome exercise.

-- Dave

D.W.Hughes@exeter.ac.uk
Department of Computer Science, University of Exeter, UK

	      ---  ${HOME} is where the .emacs is.  ---