Re: status of gcj's boehm collector?

[Jonathan Olson <olson at mmsi dot com>]

Correct.  I've been using write-barriers in g++ on embedded targets
including a29k and arm for 2 years now.  In my case, I'm not using it
for generational collection but rather to allow GC to proceed as a low
priority background thread while real-time mutators continue to run.
Generational collection doesn't buy alot on embedded targets since
heap sizes are typically 0.5 to 2.0 megs, but it's imperative that 
threads
not be blocked for the duration of a collection.

When GC isn't active, the write barriers are NOPs.  At the start of 
collection,
I enable write barriers to trace all pointer writes whether it be to heap
or stack.  This mechanism works great for a real-time collector and only
adds a single instruction per pointer write.

On the A29K, the additional instruction is an assert instruction which 
is truly
a NOP when the collector is not running.  On the ARM, it's a `bl' (CALL) 
instruction
to a statically linked function unique for the register being written to 
memory.
The write barrier function for the ARM requires 3 instructions, so each 
pointer
write to memory executes 4 instructions.

On Wednesday, December 5, 2001, at 02:12  PM, Tom Tromey wrote:

>>>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:
>
> Hans> 1) Use a software write barrier.  Insert instructions to keep
> Hans> track of heap writes.  This is what JVMs with generational
> Hans> collectors generally do.  It's not free.  It would be hard to do
> Hans> in gcj because the C++ code would have to play by the rules.
>
> Jon Olson added write barrier support to gcc in the back end.  If we
> used this approach we could add it to both g++ and gcj.  There might
> be some odd special cases, but it is doable.
>
> This sounds like something that would get put on a wish list and never
> done, unless some volunteer were really motivated.  My question to you
> is whether it would be worthwhile in the context of your GC.
>
> Tom