This is the mail archive of the
gcc@gcc.gnu.org
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: Michael Matz <matzmich at cs dot tu-berlin dot de>
- Date: Fri, 10 Aug 2001 01:53:21 +0200 (MET DST)
- cc: Fergus Henderson <fjh at cs dot mu dot oz dot au>, <gcc at gcc dot gnu dot org>
Hi,
On 9 Aug 2001, Florian Weimer wrote:
> Fergus Henderson <fjh@cs.mu.oz.au> writes:
>
> > 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.
>
> This won't work in multi-threading environment where the collector
> might be completely invisible to the compiler.
Before now Fergus explains how this can be circumvented (which he already
did in one of his earlier mails), and you come up with another way to
screw up _that_, and Fergus ... here is a may be not very satisfying
proof, of why such a collector is implementable in the frontend without
any cooperation in the backend: The backend can implement C, in C a
Turing-machine can be implemented. A turing machine can calculate every
calculable thing, ergo the backend can too (given enough memory, but
that's not a property of the backend). One of these calculable
things is a garbage collector. As Fergus already mentioned the
implementation without backend support might have horrible performance,
like an Implementation of a Raytracer on the turing machine,
but it definitely exists. qed. ;)
Ciao,
Michael.