Re: Pros and cons of high-level intermediate languages

boehm@parc.xerox.com (Hans Boehm)
Mon, 3 Aug 1992 23:45:06 GMT

          From comp.compilers

Related articles
[19 earlier articles]
Re: Pros and cons of high-level intermediate languages gat@forsight.jpl.nasa.gov (1992-07-29)
Re: Pros and cons of high-level intermediate languages moss@cs.umass.edu (1992-07-30)
Re: Pros and cons of high-level intermediate languages boehm@parc.xerox.com (1992-07-30)
Re: Pros and cons of high-level intermediate languages graham@maths.su.oz.au (1992-08-02)
Re: Pros and cons of high-level intermediate languages ridoux@irisa.fr (1992-08-04)
Re: Pros and cons of high-level intermediate languages kanze@us-es.sel.de (1992-08-04)
Re: Pros and cons of high-level intermediate languages boehm@parc.xerox.com (1992-08-03)
Re: Pros and cons of high-level intermediate languages rjbodkin@theory.lcs.mit.edu (Ronald Bodkin) (1992-08-04)
Re: Pros and cons of high-level intermediate languages optima!kwalker@cs.arizona.edu (1992-08-04)
Re: Pros and cons of high-level intermediate languages chased@rbbb.Eng.Sun.COM (1992-08-04)
Re: Pros and cons of high-level intermediate languages nfsun!gchamber@uunet.UU.NET (1992-08-04)
Re: Pros and cons of high-level intermediate languages moss@cs.umass.edu (1992-08-05)
Re: Pros and cons of high-level intermediate languages chased@rbbb.Eng.Sun.COM (1992-08-07)
[2 later articles]
| List of all articles for this month |

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
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.