GC (was: kaffe-0.8.x garbage collection problem (at least on m68k))

[Peter C. Mehlitz]

PMJI, but I think we have to reconsider the memory management in a not-so-far
future. I did some tests and found that some programs (e.g. the notorious
javac) sometimes spend most of their time collecting garbage.

During the last years, I wrote two garbage collectors for C++ and therefor have
some background on that. What might be even more interesting than the GC
mechanism itself is an allocation scheme which always knows where to get new
memory (without traversing lists to look for free slots). Most generation
scavenging collectors/allocators do. The whole idea is to make the allocation
process equally efficient as ordinary stack utilization. To my knowledge, some
ML implementations rely on this (even stack frames are heap objects). The
downside usually is an (at least) "two-halves" memory layout which roughly
doubles the amount of initially required memory (however, inactive areas can be
paged out).

With respect to the collector, I believe that a modified reference conunting
can be used in Java. The reason is, that reference counting usually has a more
serious downside than the cyclic reference problem: pointer manipulation (e.g.
doing a *p++ through a large buffer). But fortunately, this does not happen in
Java because of the non-existence of explicit pointers. It is an old idea of
mine to implement a memory management system which uses ref counting for
"simple" structures (Java Strings, StringBuffers, various kinds of streams
etc.) and some kind of a delayed two-pass traverse for all objects with
non-zero ref count.

However, this depends on some analysis / statistics of typical Java systems (it
is just efficient if there is a considerable number of zero-ref objects). Being
more than busy with biss-awt, I currently just would like to know if somebody
already is working on this.

Peter