Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!sun-barr!newstop!exodus!rbbb.Eng.Sun.COM!chased
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.lang.modula3
Subject: Re: optimization and garbage collection
Message-ID: <5839@exodus.Eng.Sun.COM>
Date: 14 Jan 91 01:56:57 GMT
References: <5142@exodus.Eng.Sun.COM> <39976@super.ORG> <5293@exodus.Eng.Sun.COM> <2v+5h2.[21@smurf.sub.org>
Sender: news@exodus.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 25

urlichs@smurf.sub.org (Matthias Urlichs) writes:
>In comp.lang.modula3, article <5293@exodus.Eng.Sun.COM>,
>  chased@rbbb.Eng.Sun.COM (David Chase) writes:

>< The garbage collector goes looking for pointers to the beginning
>< of an object, finds none, and reclaims the object (incorrectly).
>< Any temporaries referencing the object are now dangling pointers.

>It might be more reasonable to mark the object in use if there is any pointer
>anywhere into the object.

If you think about this a bit, you'll see that you get reference
counting, sort of (what if there is more than one pointer "into" the
object?).  Second problem is, how do you find these objects?  Sounds
like one more sweep step (since the optimizer hid them from the
collector).  "Into" is not really "into"; derived pointers may exist
outside the object.  Optimizing C compilers do this.  There is no
useful bound on how far "outside" the object the pointer may "point",
and no reason that there should be.

I think the answer is to get a little bit of help from the compiler;
unfortunately (in the short term) you won't get any help from a
compiler (or back-end/optimizer) for C.

David