Re: GC changes

[Bernd Schmidt <bernds at redhat dot com>]

> > > > We already need a switch to disable GC unfriendly optimizations.
> >
> > Which ones would that be?
> > And how can we verify that the generated code is indeed GC friendly?

On Tue, 16 Jan 2001, Fergus Henderson wrote:
> One way is to run lots of programs with the Boehm (et al) conservative
> collector.  The Java and Mercury front-ends may prove to be good
> sources of such test cases, since they both use that collector.
> But it would also be possible to obtain test cases from code in other
> languages by linking with a version of the Boehm collector compiled
> with REDIRECT_MALLOC enabled.
>
> > If it can't be verified with a testsuite, such a switch might as well
> > not be there, since it won't work in practice.
>
> In general a test suite can show never prove correctness.
> A test suite can only ever show the presence of errors.

Which would go a long way.  Ideally we'd need some way to compile a
program with "-fgc-safe" and then single-step through it with a simulator
while verifying that at each point all the assumptions we make for GC
still hold.

> The empirical evidence seems to be that the vast majority of the time
> it does work in practice, even without the switch.  The point of
> adding the switch would be to increase the likelihood that
> conservative GC continues to work in the future, and to make it clear
> that optimizations which are not GC-friendly are bugs if the switch is
> enabled.

That doesn't sound like a very good design.  The problem I see is that
no part of gcc was written with GC in mind.  I don't think anyone will
bother going through every line of code to verify that it does the right
thing, so, as you say, we'll only be able to talk about likelihoods.
From what I've seen people keep saying "loop might be unsafe, possibly
other passes as well" - no one really knows for sure as far as I can tell.

A switch "-fgc-safe" is a promise to the user, and we shouldn't make
promises we can't keep.

It's also an additional maintenance burden since it adds more requirements
that must be kept in mind when adding new code.  If we have no automated
way of testing it, people will break it all the time.


Bernd