Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekcrl!tekgvs!jans
From: jans@tekgvs.LABS.TEK.COM (Jan Steinman)
Newsgroups: comp.sw.components
Subject: Re: Garbage Collection & ADTs
Message-ID: <5995@tekgvs.LABS.TEK.COM>
Date: 26 Sep 89 00:50:47 GMT
Organization: Tektronix Inc., Beaverton, Or.
Lines: 46

<62342@tut.cis.ohio-state.edu (Golden Richard)>
<<wright@hsi.UUCP (Gary Wright)>>

<...I can't imagine a properly designed application where storage management is 
so complicated that the usual techniques for  programmer-managed storage 
reclamation aren't adequate.   If the programmer can't define when a certain 
object can go poof, I suspect a serious lack of understanding of the problem at 
hand.>

One who cannot imagine a need for garbage collection other than to correct for 
programmer deficiencies simply lacks imagination.

The situation is not so simple in dynamic-bound systems.  Are you claiming that 
Smalltalk, Lisp, Eiffel, Objective C, Gnu Emacs, et. al. have garbage 
collectors simply because those who program in them lack serious understanding 
of their problems?

In particular, systems designed for rapid prototyping may have storage systems 
that have completely non deterministic usage patterns.  I'm certain those who 
have used non-GC systems to build things similar to the NeXT InterfaceBuilder 
or the Smalltalk Browser have come to appreciate the need for GC.

To bring it back to the newsgroup, the problem of reusable components is 
intimately concerned with automatic storage management.  The need to document 
storage procedures is yet another reason truly reusable components are rare.

I really agree with Gary: <If our criteria for deciding whether GC is better 
than explicit memory
management is based on absolutes, we will never come to a conclusion.>  Once 
the religious give up their stubborn, blind opposition to GC, we can all begin 
to discover when to use it, when not to, and how to control it so that it stays 
out of the way when not used.  I can pound most nails with the handle of a 
screwdriver, but I'm a fool if I declare there will never be a hammer in my 
toolbox!

In particular, I don't think the combination of asynchronous GC with programmer 
storage handling has been adequately explored.  Creation and destruction of 
many data can be handled by a compiler, and most real-time systems can have 
scheduled "idle time" in which to perform overhead activities.  (A SONAR 
project I worked on performed GC during the few milliseconds then the beam was 
sweeping through the hull.)

							   Jan Steinman - N7JDB
						  Electronic Systems Laboratory
					Box 500, MS 50-370, Beaverton, OR 97077
						(w)503/627-5881 (h)503/657-7703