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: bobduff@world.std.com (Robert A Duff)
Subject: Re: Garbage Collection in Ada
Date: 1996/10/17
Message-ID: <DzFA2u.Aw@world.std.com>#1/1
X-Deja-AN: 190065535
references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se>
 <199610162305033003135@dialup100-4-3.swipnet.se> <dewar.845506067@merv>
 <3265BD97.41C6@mti.sgi.com>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-10-17T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <3265BD97.41C6@mti.sgi.com>,
Hans-Juergen Boehm  <boehm@mti.sgi.com> wrote:
>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.

I would think it would be simpler and more efficient to represent this
information as executable code.  That is, the compiler generates a
procedure for each type, and for each stack frame, that knows how to
find all the pointers.  It could take the PC as a parameter, so it could
deal with optimizations where, for example, register R1 contains a
pointer sometimes, and an integer other times.

>But in practice this seems to be limited by engineering considerations
>and table size.

I agree.  (Except I'd say engineering considerations and code size.)

Another effect might be that in a GC'ed environment, an optimizer might
cause objects to be reachable for longer than they should be.
Alternatively, the compiler might try to insert "X := null" in order to
allow garbage to be collected earlier.  Probably these are minor
effects, but there *is* some interaction between an optimizer and a
(nonconservative) gc.

>It could require the existence of a collector, and a (partially)
>conservative collector may well be the most viable implementation
>strategy.

Well, you can write "The implementation shall do garbage collection." in
a language definition, and this statement might have the desired effect
on compiler writers, but I don't know what it means in any *formal*
sense.

Anyway, I don't understand why you would want a conservative collector,
unless you're dealing with an uncooperative language/compiler (like C).
If the language "requires" gc, then there's every opportunity to have a
well-defined interface between generated code and gc, so why be
conservative?

By the way, has anybody tried Boehm's conservative GC with GNAT?  If it
works for gcc, it ought to work for GNAT, I would think.

- Bob