From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!mailrus!tut.cis.ohio-state.edu!osu-cis!killer!pollux!ti-csl!m2!gateley From: gateley@m2.csc.ti.com (John Gateley) Newsgroups: comp.lang.ada Subject: Re: Garbage Collection Message-ID: <65475@ti-csl.CSNET> Date: 12 Dec 88 05:29:12 GMT References: <124000026@inmet> <3832@hubcap.UUCP> Sender: news@ti-csl.CSNET Reply-To: gateley@m2.UUCP (John Gateley) Organization: TI Computer Science Center, Dallas List-Id: In article <3832@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes: >>From article <124000026@inmet>, by ron@inmet.UUCP: >> >> Garbage collection certainly does not come for free, but it is extremely >> useful. It frees the programmer from the need to repeatedly write >> sophisticated ADT deallocate routines and to deal with the potentially >> [...] > "Repeatedly" write sophisticated ADT deallocate routines?? [...] > where does "repeatedly" come in? The repeatedly comes in because you write more than one ADT, each requiring a/many deallocation routines. > Dealing with the details of allocation requires as much effort as > dealing with deallocation. [...] This is not true. When you allocate an object, all you need is "free" memory. The allocator does not have to worry about whether or not the object is in use etc. Deallocation, when done correctly, requires some sort of checking to make sure no currently in use object refers to the object being deallocated. This is a much more complicated problem. > [...] > Also, I disagree with the claim that a lot of effort is involved; > in my experience, DESTROY routines are among the easiest to code. > Usually, the ADT is defined recursively, lending itself to a very > easy recursive destruction procedure; [...] This method is fine, as long as no structures are shared. But when you share structure, then the problem is more complex. A sub adt-object can be used in more than one object. Deleting an object which contains this sub-object may or may not require deleteing the sub object. One answer is "reference counting", adding a field to each object which says how many people refer to it. Automating this gives reference count garbage collection, which is slower than the GC techniques in current use. So if your programming style never uses shared structure, then you don't need GC. If it does, then GC is a valuable time saving tool. > Bill Wolfe > wtwolfe@hubcap.clemson.edu John Gateley gateley@tilde.csc.ti.com