Re: ObjC configured --with-objc-gc needs external Boehm gc

[Ovidiu Predescu <ovidiu at cup dot hp dot com>]

As you pointed out, I think we should set the ALL_INTERIOR_POINTERS and enable
the threading as it doesn't seem to add a substantial overhead.

I briefly looked in the GCC source code: is the garbage collector itself
distributed with GCC? I couldn't find it anywhere; am I missing something?

Thanks,
Ovidiu

On Tue, 16 Jan 2001 16:21:50 -0800, "Boehm, Hans" <hans_boehm@hp.com> wrote:

> > From: Helge Hess [mailto:helge.hess@skyrix.com]
> > "Boehm, Hans" wrote:
> > > I can't think of any fundamental problems.  I suspect 
> > Objective C normally
> > > wants the collector built to recognize all interior 
> > pointers, where gcj
> > > builds it without that option, so that interior pointers 
> > are recognized only
> > > if they're on a stack.  This is currently a build time 
> > option, but that
> > > probably doesn't save very much anymore over making it a 
> > runtime option.
> > 
> > Hm, I don't remember - all-interior-ptrs are required for 
> > untyped memory
> > ? The ObjC runtime uses typed allocation, so it might not require
> > all-interior-ptrs.
> The question is really whether the last pointer to an object can point to
> the inside of the object.  If you can get and save a pointer to a field in
> object A, save it inside object B, and then drop the pointer to A, you need
> ALL_INTERIOR_POINTERS.  Thus C/C++ more or less need it, while Java doesn't.
> If you can embed C structs inside Objective C objects, I suspect Objective C
> also needs it?
>   
> > 
> > > Does Objective C normally use the collector with thread support?
> > 
> > I think that this is 50/50. The problem is that threading currently
> > slows down the runtime to some degree and therefore is often 
> > turned off
> > if threading is not required.
> Aside from a tuning problem in current collector versions, it should
> currently cost basically one test-and-set (probably 5-30 cycles depending on
> the processor) on entry, and a store on exit of each malloc call.  The
> uniprocessor cost with thread-local allocation (as in GC6.0) is probably
> about the same, though it scales much better on multiprocessors.
> 
> Hans
>