From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3498dd887729ed19 X-Google-Attributes: gid103376,public From: Hans-Juergen Boehm Subject: Re: Garbage Collection in Ada Date: 1996/10/15 Message-ID: <3263ECCD.167E@mti.sgi.com>#1/1 X-Deja-AN: 189683478 references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se> <199610132138291604607@dialup101-6-14.swipnet.se> cc: boehm content-type: text/plain; charset=us-ascii organization: Silicon Graphics Inc., Mountain View, CA mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.0S (X11; I; IRIX 6.2 IP22) Date: 1996-10-15T00:00:00+00:00 List-Id: Robert A Duff wrote: > To me, this sounds backwards. Virtual origins are a useful > optimization, and if they break your GC, then your GC is broken. It's > not the compiler's fault. It's certainly possible to implement a GC > that works in the presence of this optimization. And there are many > other examples of optimizations that will break the typical > "conservative" GC, but a proper non-conservative GC can work properly. > The term "conservative" is bogus, IMHO, since if you do certain things > in your code, or your friendly compiler-writer does certain > optimizations, it makes the GC *liberal* -- that is, frees in-use data. I think it's important to distinguish 2 kinds of "conservative" garbage collection: 1. A garbage collector that doesn't have perfect pointer identification information, but can identify a superset of the valid pointers. In the long run this is the only kind of conservative GC that makes sense. Our collector can be used in this way with some C compilers (e.g. lcc, gcc with the preprocessor from my PLDI 96 paper, most compilers in debugging mode). Assuming minimal and mostly checkable restrictions on the input, this cannot result in freeing of in-use data. (Note that the GC-unsafe use of virtual origins in C SOURCE code is a BUG according to the ANSI C standard. See my PLDI 96 paper or the standard for details.) There are sometimes performance reasons for using such an approach even when exact pointer-identification information could be made available. 2. Use of the same collector as above with a compiler that does not ensure that pointers are maintained in recognizable form at run-time. This is a hack that happens to work 99.99% of the time, and happens to be useful at present. The strongest correctness argument one can make is that at present it appears to be at least as reliable as as many compiler optimizers themselves. The downside is that it works well enough that there is little incentive for more GC-friendly optimizers. > Avoiding certain things in my code is tolerable, but it makes me nervous > to think that the new version of a compiler, with a smarter optimizer, > might come along and break the conservative GC. In the past "smarter" optimizers have often broken the ANSI-conforming parts of our collector, too. (These were not released SGI compilers. Some of the were released "production" compilers from other vendors.) -- Standard disclaimer ... Hans-Juergen Boehm boehm@mti.sgi.com