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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3498dd887729ed19
X-Google-Attributes: gid103376,public
From: ohk@edeber.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB)
Subject: Re: Garbage Collection in Ada
Date: 1996/10/16
Message-ID: <OHK.96Oct16081802@edeber.tfdt-o.nta.no>#1/1
X-Deja-AN: 189752571
references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se>
organization: Telenor Online Public Access
newsgroups: comp.lang.ada
Date: 1996-10-16T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <dewar.845388021@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

   Lines: 40
   References: <01bbb910$f1e73f60$829d6482@joy.ericsson.se> <199610132138291604607@dialup101-6-14.swipnet.se> <Pine.GSO.3.93.961014050707.23547A-100000@sky.net> <19961015122319668722@dialup98-6-12.swipnet.se>
   NNTP-Posting-Host: merv.cs.nyu.edu
   X-Newsreader: NN version 6.5.0 (NOV)

   Lars said

   "With GC the problem of "clean up" of memory is defined away. There is no
   way to be "sloppy" about deallocating memory with GC. There is no
   problem, pure and simple. That this is hard to accept is IMHO a clear
   indication that this really is a hard problem (without GC). We are so
   afraid of memory leaks that we find it very hard to accept an automatic
   solution. Note: this doesn't mean that GC solves every conceivable
   memory related problem, but knowing when to release memory is solved so
   the result is not "slop to clean up"."


   Hmmm! I am surprised anyone would write this if they had used GC languages.
   The problem of cleanup is not define away at all, and indeed, in some
   respects can be trickier, because you don't think about it up front as you
   have to in a system where you use finalization for freeing things, or even
   more manual techniques.

   The problem is that it is all too easy to have a global variable around
   that accidentally holds on to a giant structure. Or for example, depending
   on your implementation, taking the 'Access of one field of one record in
   some big structure may end up holding on to an entire subgraph that you
   do not need.

Yes, but is this really a problem? What you really want to avoid is
the program gobbling up ever-increasing amounts of memory over
time. If you have global variables around pointing to objects, it is
possibly just because you need to avoid egtting your structure
deallocated! When I learned Simula after having programmed in Fortran
for some time, it took some time to adjust to the new environment, but
I experienced GC as a clear advantage. But then I didn't do real-time
systems in Simula....

   You may in practice need to be just as careful about adding

      Junk := null;

   statements to your program as you are now about adding

      Free (Junk);

   statements to your program now. 

Yes, if you have the habit of using lots of global variables,
otherwise it will be deallocated some time after the variable goes out of
scope. (As I am 100 percent sure that you know)

   GC is certainly a magic bullet solution to the problem of accidentally
   freeing storage that should not be freed, but it is NOT a magic bullet
   with respect to not freeing things that should be freed. People who 
   approach a GC language environment with this expectation will be
   disappointed!

In theory you are right, but it is strange I have never heard
complaints about this problem from the Lisp hackers next door.