Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!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: Component with garbage collection
Message-ID: <6600@hubcap.clemson.edu>
Date: 27 Sep 89 01:02:55 GMT
References: <130200012@p.cs.uiuc.edu>
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 23

From article <130200012@p.cs.uiuc.edu>, by johnson@p.cs.uiuc.edu:
> [Types in a compiler, which share structure]

   This is basically equivalent to the disconnected subgraph problem;
   both are tantamount to presenting the general garbage collection
   problem and saying "here's a problem which requires garbage collection".

   Obviously, for any problem which either is the general GC problem or
   is analytically equivalent, GC algorithms can be used.  Maybe there
   are even a fair number of situations in which this is the case.  If
   so, then GC is worth keeping around.  In these cases in which the ADT
   implementor doesn't have any useful information to communicate to the
   storage management system; the GC system can still raise an exception 
   if it can't find any more space.  Also, the implementor can still do
   a managed version if variable response time is a problem. 

   In general, though, it still seems more efficient to communicate any
   information regarding the availability of storage which might be known
   by the ADT implementor, so that the work of searching for garbage can
   be concentrated on those situations in which it cannot be avoided. 


   Bill Wolfe, wtwolfe@hubcap.clemson.edu