Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rutgers!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: Garbage Collection & ADTs
Message-ID: <6591@hubcap.clemson.edu>
Date: 26 Sep 89 19:10:49 GMT
References: <604@hsi86.hsi.UUCP>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 81

From wright@hsi.UUCP (Gary Wright):
> Bertrand Meyer claims that programmer-controlled deallocation "is
> unacceptable for two reasons: security and complication of program
> writing."  By security, Meyer means that programmers [...] will
> make mistakes and will dispose of objects that still have active 
> references.  

     Unless they leave the task to an ADT instead.
 
> Complication refers to the fact that simply disposing
> of an object is not sufficient, all internal objects must also
> be disposed.  Meyer calls this the "recursive dispose problem":
> 
> 	This means that a specific release procedure must be
> 	written for any type describing objects that may refer
> 	to other objects.  The result will be a set of mutually
> 	recursive procedures of great complication.

   Not true.  The user supplies a Destroy procedure for whatever
   is being stored.  The ADT, in the course of destroying itself,
   will call upon the user's Destroy procedure to handle the user's
   data type.  The writer of the Destroy procedure need only consider
   destroying his ADT, since the user's Destroy procedure can be relied
   upon to destroy all lower levels.  It's really rather simple.

> Instead of the applications programmer worrying about storage, the ADT
> designer must worry about it.  

   Precisely.  As an ADT designer, I consider the task of storage
   management to be among the least of my problems.  The difficult
   part is providing all the concurrency-related hard guarantees,
   which languages like Eiffel manage to avoid by not providing
   multitasking in the first place. 

> My hunch is that the distiction between an ADT designer and an 
> applications programmer is clear for objects like linked lists, 
> stacks etc. but that it is not so clear the farther away from the 
> basic data structures you get.  

   The distinction is clear: the ADT specification separates the
   application programmer from the ADT implementor, regardless of
   whether you perceive the structure as "basic" or not. 

> I wonder if the overhead related to having ADT's managing storage
> via copying, and redundant code (all the recursive dispose procedures)
> doesn't come close to the overhead for GC.

   Probably not, since this approach can exploit more information;
   it doesn't have to worry about figuring out whether or not a
   piece of space can be released, since it already knows it can.
   The Destroy procedures convey information which does not have
   to be rediscovered at great and continuing expense. 

> It should be noted, that Meyer advocates a GC facility that is
> incremental in nature (not bursty), and can be explicitly turned on or
> off when necessary (e.g. when real-time constraints exist).
> 
> Your turn. :-)

   We know that GC can coexist with managed components, as in Ada,
   where components can declare that the GC system (if any) must
   not operate on objects of a managed type.  We can easily agree
   that if GC is provided, there must be a way for managed types
   to turn it off as far as they are concerned, while leaving it 
   potentially on for others.  If a given piece of code contains 
   only managed types, then the compiler should notice this fact 
   and exclude GC code from the executable.

   The original point was that not all users can tolerate GC
   (real-time users in particular); on the other hand, all GC users
   can use managed components with no problems.  Therefore, if
   a component is to be designed for the widest possible audience,
   that component must manage its own storage.  If components are
   used which meet the highest possible standards, then we don't 
   have to worry about whether our components will stop working 
   when we do maintenance (which might introduce multitasking, 
   real-time operation, etc.) on our application; using GC introduces
   such weaknesses, in addition to giving an *avoidable* run-time cost. 


   Bill Wolfe, wtwolfe@hubcap.clemson.edu