Re: how to generate code for (a,b):=(b,a)

Robert A Duff wrote:
> IMHO, this is the fault of the GC, not the compiler. So-called
> "conservative" GC's are supposed to work properly in "hostile"
> environments. In this case, the compiler is doing something perfectly
> valid according to the language definition (and might in fact be a
> useful optimization).
>
> If the GC and the compiler have a contract between them, then all is
> well. If the GC wants to go around collecting garbage according to what
> it *thinks* the compiler might do, well, I have no sypathy for the GC
> when it's wrong.


A conservative GC will never work in a really hostile environment.
Mark Weiser and I used the term "uncooperative". Probably "minimally
cooperative" would have been a better term.


As the moderator pointed out, there is no way to implement a
reasonable and fully safe garbage collector without some contract
between the compiler and garbage collector. The advantage of a
conservative collector is that the contract is such that


1) It is probably satisfied by most existing compilers when generating
debuggable code with optimization disabled. (A compiler that does the
above with optimization disabled is likely to be at least slightly
broken. If I stop the program in the middle of the xor sequence, the
debugger is likely to give me some pretty strange values for a and/or
b.)


2) There exist compilers with which it is always safe. (Dave Hanson
claimed that this true for lcc. I claim it is true for gcc with the
preprocessor described in my 1996 PLDI paper.)


3) It is satisfied by most existing compilers for most programs. The
failure rate for existing compilers seems to be less than that due to
outright optimizer bugs, at least based on my experience. (That
applies to compilers produced by many vendors. I'm not maligning
anyone in particular.)


This gives them a number of advantages (and disadvantages) relative to
other GC strategies. Currently they're the only game in town for C,
they're usually the highest performance and most flexible solution for
C++, and they currently seem to be the highest performance solution
for Java (though a fully conservative collector is almost certainly
not the right solution for Java).


I think all of this argues that eventhough compiler writers never
promised not to break conservative collectors, there's a strong
argument for not doing so for a marginal performance advantage. At
least it would be nice to provide an option to disable such
techniques.


--
Hans-Juergen Boehm
boehm@mti.sgi.com
--

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