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.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC 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: Thomas.Kendelbacher@erno.de (Thomas Kendelbacher)
Subject: Re: Garbage Collection in Ada
Date: 1996/10/17
Message-ID: <5453vh$6dt@mailsrv2.erno.de>#1/1
X-Deja-AN: 190058326
references: <dewar.845388021@merv>
organization: Daimler-Benz Aerospace, Space Infrastructure
reply-to: Thomas.Kendelbacher@erno.de
newsgroups: comp.lang.ada
Date: 1996-10-17T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <dewar.845388021@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>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.
>
>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, but one difference is: you may write "Junk := null;" as often as you like,
but beware of calling "Free (Junk);" more than once (with any aliases of "Junk"),
or when the value of "Junk" may have been achieved using 'Access.
Handling proper deallocation is much easier with GC, IMHO, which leads to simpler
designs and easier-to-read program code.

To my experience with dynamic memory handling, not freeing things that should be
freed is certainly an important problem, but freeing something too often or too
early, accidentally, is much more dangerous because it usually leads to a creeping
corruption of data structures, without warning, which can be hard to detect (the
program starts to act "strange" at some point) and hard/expensive to debug.
With a memory leak, OTOH, at least your program will behave as it should, as long
as its heap memory lasts. Automatic GC avoids the former (the more expensive/
dangerous problem) entirely, and helps avoid memory leaks very well, with
minimal precautions by the programmer:

To continue your example, the solution to the cited problem is simply "avoid
global variables." It's as simple and common-sense as that; don't we do that
anyway, as far as possible? And it's simple to make a design such that it does
take care of the few that remain. (Of course, one has to be aware of the
potential problem; but if you are, it's really easy to avoid it. And if there's
still a memory problem, you know *exactly* where to look.)

P.S. The second problem, a record field accessed from the outside via 'Access,
locking the entire record from GC until the outside access is gone, is simple to
solve, too. If you plan to "share" a record field in this way, you could decouple
the shared object from the record by storing in the record field itself an access
to it, and pass this access value around as you like. With automatic GC,
you don't have to worry when to deallocate it.

-- 
Thomas Kendelbacher   |   email : Thomas.Kendelbacher@erno.de (preferred)
DASA RI / Abt. RIT14  |   voice : +49 421 539 5492 (working hours)
Postfach 28 61 56     |      or : +49 421 576 9670 (any other time)
D-28361 Bremen        |     fax : +49 421 539 4529 (any time)
Germany