This is the mail archive of the
mailing list for the GCC project.
Re: GC changes
- To: Bernd Schmidt <bernds at redhat dot com>
- Subject: Re: GC changes
- From: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Date: Wed, 17 Jan 2001 00:36:28 +1100
- Cc: Jamie Lokier <egcs at tantalophile dot demon dot co dot uk>, Mike Stump <mrs at windriver dot com>, <amylaar at cambridge dot redhat dot com>, <gcc at gcc dot gnu dot org>, <geoffk at geoffk dot org>, <tej at melbpc dot org dot au>
- References: <20010116010800.A29939@hg.cs.mu.oz.au> <Pine.LNX.firstname.lastname@example.org>
On 16-Jan-2001, Bernd Schmidt <email@example.com> wrote:
> > 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.
It's certainly not an ideal design. But unfortunately compilers that
support garbage collection and have the same advantages as GCC are
hard to find. When push comes to shove, many people will choose to
use GCC in conjunction with a conservative garbage collector,
accepting the risks that this involves, since even with those risks
overall this combination has many advantages over the competitors.
The Mercury and Java front-ends to GCC are examples of this.
> 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.
You're right that we shouldn't make promises that we can't keep. So
you could make a reasonable argument that the documentation for this
switch should explicitly say that it might not work, since no-one has
fully analyzed all of the GCC source code to ensure that it is
respects the switch.
However, people are making such assumptions anyway. And the emperical
evidence is that such assumptions are not unreasonable. My personal
practical experience, based on having tested millions of lines of C
code with GCC, is that bugs in GC safety are much rarer than ordinary
bugs in other parts of GCC, even though GCC does not explicitly
support GC safety. I have discovered and reported many bugs in GCC.
I have not yet discovered any problems due to optimizations breaking
> It's also an additional maintenance burden since it adds more requirements
> that must be kept in mind when adding new code.
That's true, but I think the burden is well worth it. Garbage
collection is undoubtably the way of the future. If GCC doesn't
support garbage collection then it will slowly but surely lose market
> If we have no automated way of testing it, people will break it all the time.
People break GCC all the time. GCC is always broken.
What really matters is whether the bugs show up in practice.
If the bugs show up in practice, then they can be tested for and fixed.
Fergus Henderson <firstname.lastname@example.org> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.