> 
> Since the GC runs as a low priority thread, and context switching is
> not preemptive, don't expect it to run unless you leave some free CPU
> for it to run.  Inserting `Thread.sleep(10);' in the loop may help
> too.  I don't think `Thread.yield();' would help, because GC gets
> lower priority.
> 

 Actually, Kaffe in its current version does not have asynchronous gc.
That is, the garbage collector is only explicitly invoked by a thread
when it tries to allocate an object and can't.  So even if no thread
is runnable, the gc will not run.

This is controlled by a condition variable on which the gc thread blocks.
The garbage collector itself runs with the highest priority (when invoked),
and so does the finalizer.  This is, however, of little importance because
the gc disables interrupts during the marking phase, preventing any other 
thread from running.  At some point during the sweep phase, the garbage 
collector reenabled interrupts.  Despite the fact that is runs at the
highest priority, it can then lose the CPU due to the contention for the 
lock protecting memory allocation (gc_heap_free).  

Having a asynchronous gc requires the use of a read or write barrier.
That is, all running threads (called "mutators") must inform the gc when they
write a pointer to an unscanned (white) object into an already scanned
(black) object.  This was at some point implemented (GC_WRITE), but never
really worked and is currently disabled.

To be correct, the write barriers were used to implement incremental
gc.  Incremental gc does a bit of gc at every allocation.  Both asynchronous
and incremental gc require barriers.

	- Godmar