Newsgroups: | comp.compilers |
From: | boehm@parc.xerox.com (Hans Boehm) |
Organization: | Xerox PARC |
Date: | Mon, 3 Aug 1992 23:45:06 GMT |
References: | 92-07-064 92-08-004 |
Keywords: | translator, design |
graham@maths.su.oz.au (Graham Matthews) writes:
>(Hans Boehm) writes:
>>>>But the C standard does not guarantee that C compiler
>>>>optimizations are safe in the presence of such a collector.
>graham:
>>[recording local pointer variables is slow]
>Perhaps we are arging at cross purposes here. As far as I remember the
>original post argued that C could not be used as an IL because of garbage
>collection. I was attempting to argue that this is not so, that the
>problems of garbage collection and moving pointers can be dealt with by
>emitting "correct" C code. Granted you may have to do some work to get it
>right.
>Now the argument appears to have shifted to one of performance. I agree
>that the peformance will be affected. My question is then whether the
>performance loss is due to C or due to using GC. Surely in the presence of
>GC one is always going to take a performance hit beacause the values of
>pointers can change at any time?
I think we are making some conflicting assumptions. I thought we were
discussing performance.
If your source language is something like Modula-3 or Cedar/Mesa, then one
reasonable approach is to not have the collector move objects, or at least
not have it move objects that are referenced from registers and the stack.
In that case, with the right kind of C compiler, it suffices to keep some
pointers live a little longer than otherwise necessary. Thus the only
inherent penalty is the cost of a few extra registers in a few places. My
guess is that for most code on register-rich machines, this does not lead
to a significant performance loss.
For more allocation intensive code, things may be different. However
Bartlett's Scheme-to-C compiler also gets away with this strategy, though
he does move objects that are not pointed to by the registers or stack.
(I'm not sure how well a completely nonmoving collector can do with ML or
Scheme. My guess is that you can get allocation rates down sufficiently
with clever optimization to make it a reasonable strategy.)
If you do want to use a fully copying collector in conjunction with C,
then you are right. In fact, things get pretty messy in the presence of
multiple threads.
Hans-J. Boehm
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.