This is the mail archive of the
mailing list for the GCC project.
Re: a .NET alternative (GJC et al)
- To: Florian Weimer <Florian dot Weimer at RUS dot Uni-Stuttgart dot DE>
- Subject: Re: a .NET alternative (GJC et al)
- From: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Date: Fri, 10 Aug 2001 03:51:09 +1000
- Cc: gcc at gcc dot gnu dot org
- References: <200107280643.XAA13992@morrowfield.home> <20010728151858.A10834@murlibobo.cs.mu.OZ.AU> <firstname.lastname@example.org> <200107290857.BAA21039@morrowfield.home> <20010730134749.A23349@hg.cs.mu.oz.au> <email@example.com> <20010731085348.A18328@hg.cs.mu.oz.au> <firstname.lastname@example.org>
On 09-Aug-2001, Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE> wrote:
> Fergus Henderson <email@example.com> writes:
> [GC, backend cooperation
> > The reason that this technique works is that the back-end compiler
> > can't do any fancy optimizations on locals.p and local.q, since
> > &locals has been stored in a global variable and so any function
> > call might update them.
> But there is a subtle form of backend cooperation lurking here: You
> assume that the backend does not know too much about the functions
> being called. In fact, if there isn't a collector, the stack frame
> marking does not have any externally visible effect, so it is legal to
> optimize it away completely.
> In order to make things work, you have to throw in a few volatile
> qualifiers here and there, I think, which will deteriorate performance
No, neither volatile nor back-end cooperation is needed.
If there isn't a collector, the back-end can (if it is very
clever, and uses intermodule optimization) optimize away the
stack frame marking. Great! Fantastic! I wish GCC was that smart! ;-)
If there's no collector, that's exactly what I want the back-end to do.
If there *is* a collector, however, the back-end can't optimize *away*
the stack marking, because the collector gets passed (via the
global variable) a linked list of all the stack frames, and
it traverses them. The back-end may perhaps be able to do some
optimizations, for example inlining, which may mean that what the
garbage collector sees in its linked list don't correspond directly
to the actual stack frames. No problem. If the compiler is really clever it
may even decide to specialize the garbage collector for each different
call to the allocation routine. Great! That won't break the collector;
it may even help it run faster.
Fergus Henderson <firstname.lastname@example.org> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.