Re: SpecJVM98 (was: assembler warning when compiling obfuscated

[Godmar Back <gback at cs dot utah dot edu>]

> 
> My problem with kaffe was the GC benchmark, on which it lost to even the
> Blackdown JDK, and lost by a factor of 4 to gcj.  Has anybody looked more
> closely at why this is?  Is there a good reason for it, e.g. an (overzealous
> on a PC?) attempt to keep the heap small?
> 

The main problem with Kaffe's gc is that it's a conservative mark-and-sweep
collector, but it keeps all objects in doubly linked lists at all times.

So if an object changes color from say gray to black, it is actually moved
from the white list to the gray list.  This hurts.  There is no mark stack,
instead, marking is done by moving objects from the white to the gray list.
Similarly, the sweep phase is implemented by iterating over the list of 
objects and unlinking and freeing each object individually.  I think those 
are the main sins.

I think this setup reflects an incomplete attempt to implement a 
threadmill-like incremental scheme, which was never completed.  Some work
is being done, but resources are limited.  Integrating your gc is also
a possibility, and because of its maturity would probably help things, but
it also requires time and dedication.  But it is not an impossible task
the way the gc interface is structured.

	- Godmar