status of gcj's boehm collector?

Wed Dec 5 16:16:00 GMT 2001

I think there's an inherent difference between the embedded and workstation
or server situation here. It seems to me that to get this to work cleanly
in the workstation environment, we'd need to get all the libraries that
might possibly be used to play by the write-barrier rules. (Consider a CNI
function that calls qsort() on a pointer-containing array.) I don't think
that's feasible. And it's not clear to me that there are clean half-way
measures.
In the embedded case, if you have control over the whole system, or at least
all possible CNI code, this doesn't really matter. In this case, I think it
wouldn't be too hard to get our collector to take advantage of it. You
could probably just set the heap block size to something small (e.g. 512
bytes) and add another (fairly trivial) virtual dirty bit implementation in
os_dep.c. I expect you would get significantly lower latency as a result.
But the collector is not designed for hard real-time bounds.
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.
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
>