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