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

["Boehm, Hans" <hans_boehm at hp dot com>]

> I'm sure I read somewhere (in one of your papers, perhaps) 
> that some compiler
> optimizations can hide base pointers and necessitate 
> ALL_INTERIOR_POINTERS even
> if interior objects are not explicitly accessed in code.
> 
> I believe the java frontend always maintains base pointers to 
> live objects, not
> sure about objc.
> 
Short answer:
Yes, there are potential problems.  But I don't think they affect this
discussion much.

Longer answer:
The collector always considers interior pointers from the stack or the
registers to be valid, even if it's not configured with
ALL_INTERIOR_POINTERS.  The ALL_INTERIOR_POINTERS option affects only
pointers stored in the heap or static data areas.  It seems unlikely that
the compiler would introduce stores of derived pointers into either the heap
or static data areas (since this would probaly introduce thread-safety
issues if nothing else).  Thus I think it's mostly a source language/client
code issue as to whether this is needed.

This unfortunately doesn't completely solve the problem, since there are
cases in which the compiler potentially introduces a derived pointer that
doesn't point to anywhere in the original object, and yet that is logically
the only reference to the object.  The canonical example is

char *a = GC_malloc( ...);
char *x;

x = a + (i - 1000);
<a dead>
... *x ...

which may be compiled to

a -= 1000;
<GC occurs here, reclaiming a>
... *(a + i) ...
<oops!>

In this form, this can only be done by the compiler, since the "a -= 1000"
assignment is not legal C pointer arithmetic.

I know of no way to avoid this problem, no matter what kind of GC you use,
without teaching the compiler that there might be a garbage collector.  This
can be done by telling the backend that "a" is live until the dereference of
*x occurs.  There are more details in my 1996 PLDI paper, and in a paper
that David Chase and I wrote before that.

It sounds like gcc doesn't currently guard against this, no matter what the
front end.  This really needs to be fixed eventually.  On the other hand,
this problem seems to be EXTREMELY rare in real code.  (It's basically
impossible when generating debuggable unoptimized code.)

Hans