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 <boehm@mti.sgi.com>
Subject: Re: Garbage Collection in Ada
Date: 1996/10/16
Message-ID: <3265BD97.41C6@mti.sgi.com>#1/1
X-Deja-AN: 190269189
references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se>
 <199610132138291604607@dialup101-6-14.swipnet.se> <dewar.845247229@merv>
 <19961014115513529729@dialup105-2-16.swipnet.se> <dewar.845470185@merv>
 <199610162305033003135@dialup100-4-3.swipnet.se> <dewar.845506067@merv>
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-16T00:00:00+00:00
List-Id: <comp.lang.ada>


Robert Dewar wrote:
> 
> No, you are confused, if a language expects GC, and if a proper GC is
> incorporated, there is no respect in which the presence of GC inhibits
> optimizations. Where did you get this idea?

For systems I've seen it does inhibit some optimizations, ar least to
the extent that proper use of a conservative collector inhibits
optimizations.  Especially in multithreaded systems, there must be a
recognizable pointer to every accessible object at every program point
at which a GC might occur.  Often this is between every pair of
instructions.  In a nonconservative system you could generate
arbitrarily complex tables to allow reconstruction of those pointers.
But in practice this seems to be limited by engineering considerations
and table size.  This effect is minor (perhaps a few percent, see
e.g. my PLDI 96 paper), but it's not completely negligible.  (Of
course write-barriers and especially read-barriers can have a
moresubstantial effect on the generated code, if they're needed.)
> 
> It is true that a conservative collector depends on assuming the absence of
> no optimization, but there is no way that a language definition could
> somehow "sanction" a conservative collector.
> 
It could require the existence of a collector, and a (partially)
conservative collector may well be the most viable implementation
strategy.


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