This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: a .NET alternative (GJC et al)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]