Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!gatech!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.sw.components
Subject: Re: Real-time Garbage Collection
Message-ID: <6506@hubcap.clemson.edu>
Date: 19 Sep 89 15:41:20 GMT
References: <1917@hydra.gatech.EDU>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 55

From tynor@prism.gatech.EDU (Steve Tynor):
>>>>   It's safe to do so:
>>>>     1) When the variable goes out of scope
>>>>     2) When the programmer specifies that it's to be destroyed sooner.
> 
> Whether a reference to a shared object is a pointer, or is hidden via some
> clever encapsulation, I can't see how the programmer can be expected to know
> when to explicitly deallocate the reference without maintaining reference
> counts (whether he does it, or the ADT - it's still reference counting) or
> relying on GC (or assuming that references are _never_ shared - which seems
> like a simplistic assumption).

   OK, first let me clarify my position.  The primary use for pointers
   is simply to implement abstract data types -- lists, trees, graphs, etc.;
   by shielding the user from the details of implementation, we can keep
   the user from having to worry about manipulating pointers.

   Now your question, I believe, is "What if the user wants to store
   pointers in a container?"... the response is that the user probably
   should seriously consider the possibility that s/he is making an 
   inappropriate use of pointers.

   Let's suppose the user has an object with lots of "inertia", which
   causes the user to initially think that pointers are a good way to
   "move" this object as necessary.  This can be addressed with a
   technique which applies to an even harder problem: the case in
   which the object is not even locally present.  The solution is
   to assign unique identification numbers to objects of the type,
   keep the objects in a database (which may of course be a distributed
   database), and then deal with the identification numbers instead.
   
   Identification numbers have many nice properties: they can be arbitrary
   abstractions (e.g., encoding certain properties of their client objects),
   they are totally machine-independent, and they are not subject to any
   a priori limitations.  Information regarding the maximum lifetime of the 
   object is a particularly good property to encode into the identification
   number, since the holder can then quickly check whether the object has
   expired without even consulting the database.  Where objects can have
   an infinite lifetime, a protocol can be devised whereby the database
   must be checked at least once per some arbitrary time period by all
   users, which will permit identification numbers to be recycled after
   one full time period of nonexistence.  Other protocols might be used
   depending upon the characteristics of the specific object involved.
   The techniques for managing the active range of identification numbers
   can also be quite sophisticated.

> I am (as we speak) trying to implement a ADT (in Ada) which contains 
> objects whose lifetimes are not lexically scoped and to which many 
> other objects may refer.  I'd be very happy to avoid reference counts
> and GC if someone can suggest a way to do so!

   Consider it done. 


   Bill Wolfe, wtwolfe@hubcap.clemson.edu