status of gcj's boehm collector?

Thu Dec 6 07:08:00 GMT 2001

On Wednesday, December 5, 2001, at 05:15 PM, Boehm, Hans wrote:
>> It also sounds to me Jon's approach is more expensive (in execution 
> time,
> not space) than what you would be willing to tolerate for a workstation
> application. Even if the collector is not active, you presumably need a
> function call, plus a test of a global for every stack write on many, 
> though
> not all, architectures. (Or perhaps you can keep the global flag in a
> register, and make the call conditional? It sounds like the A29K 
> approach
> is along these lines? That again would be hard if we have to stick to a
> standard ABI on a workstation or server.) You probably have to do 
> something
> like this to get really low latencies, but I think most users wouldn't 
> want
> to pay for it.

There's no need for a write barrier check for every write, only pointer 
writes
provided the software is well behaved enough not to declare pointers as 
integers.
At compile time GCC knows when it's assigning to a pointer and can 
generate
the extra code for the write barrier. Certain functions like memcpy() 
which do
bulk memory copies which may contain pointerful memory require a call to 
the
a special method in the collector like:
	gc->scanIfCollecting(mem, size);
Actually, the A29K is remarkably well suited for write barriers since it
has a zillion global registers and has assert instructions. In this 
case, the write
barrier is just the single instruction:
	asltu		V_WRITEBARRIER,PointerReg,SysWriteBarrier
This instruction takes the V_WRITEBARRIER trap whenever PointerReg is
not less than the SysWriteBarrier register. Normally, SysWriteBarrier 
contains
FFFFFFFF, but during garbage collection contains the start of heap. 
Thus,
on the 29K, the write barrier only adds a single instruction which is 
effectively
a NOP when GC is not running.
On other architectures, you can either inline the write-barrier check or 
call
a function unique for the particular register being written. But again, 
the only cost
is for pointer writes not for every memory write.
> Hans
>>> -----Original Message-----
>> From: Jonathan Olson [mailto:olson@mmsi.com]
>> Sent: Wednesday, December 05, 2001 1:33 PM
>> To: tromey@redhat.com
>> Cc: Boehm, Hans; 'Adam Megacz'; java@gcc.gnu.org
>> Subject: Re: status of gcj's boehm collector?
>>>>>> 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
>>