Re: robustness vs. conservative GC

[ebiederm at xmission dot com (Eric W. Biederman)]

Fergus Henderson <fjh@cs.mu.oz.au> writes:

> On 30-Jul-2001, Tom Lord <lord@regexps.com> wrote:
> > 
> > 2. In the face of an aggressively optimizing C compiler, one that
> >    sometimes disguises pointers, conservative GC can fail to protect
> >    some live objects, resulting in program failures.  This is a 
> >    famous limitation of conservative GC.
> > 
> >    Sticking to a specific compiler and options known not to disguise
> >    pointers avoids the bug, but is a fragile solution.
> 
> I agree.  It would be better to have a specific compiler option, called say
> `-fdont-hide-pointers' or `-fconservative-gc', which guarantees that the
> compiler won't perform any such optimizations.
> 
> Does anyone know of any current GCC optimizations which might hide pointers?

You'd have to check the specifics but I would look at loop optimizations.
There is a classic optimization where multiple pointers, or counters that
are incremented every time through a loop are combined into the same register,
and computation is used when necessary to recover the pointer.

I think GCC does something like the above but I haven't checked.  For
the above optimization it is probably sane to simply store the
original pointer values outside of the loop. 

> 
> > In my experience, both bugs (#1 and #2) are likely to eventually show
> > up in deployed systems,
> 
> If you have specific experience of #2 occurring in deployed systems,
> I'd be interested in hearing about that.
> 
> > Fergus Henderson made the claim that an exact GC implemented without
> > compiler support is likely to perform worse than one implemented with
> > compiler support.  I don't know what "likely" means in that claim, but
> > I don't see any a priori reason to believe there will necessarily be
> > performance problems.
> 
> Any scheme for doing exact GC without cooperation from the compiler
> back-end needs to store pointers in a known location on the stack, rather
> than in registers, so that they can be updated when objects are moved.
> This denies the back-end compiler freedom to put such pointers in
> registers.  Register allocation obviously has a big effect on
> performance.

Hmm.  If you allow moving GC you have a more strenuous constraint than
with conservative garbage collectors which never move the data.  Exact
collectors don't need to move the data.  To allow a moving collector
you need to either dumb down the compiler, yuck.   Or to create
something like the current eh framework so you can call out of line
code to find and update the pointers. 

Eric