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: Hans-Juergen Boehm Subject: Re: Garbage Collection in Ada Date: 1996/10/15 Message-ID: <3263E1A9.41C6@mti.sgi.com>#1/1 X-Deja-AN: 189662935 references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se> <199610132138291604607@dialup101-6-14.swipnet.se> <19961015122319668722@dialup98-6-12.swipnet.se> cc: boehm content-type: text/plain; charset=us-ascii organization: Silicon Graphics Inc., Mountain View, CA mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.0S (X11; I; IRIX 6.2 IP22) Date: 1996-10-15T00:00:00+00:00 List-Id: Robert Dewar wrote: > 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. > > 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! That's certainly all true. But it's important to remember that there are 2 important differences between inserting Junk := null; and Free (Junk); 1. The first asserts only that the pointer Junk is no longer needed. It makes no claims about any other uses of the object referenced by Junk. If another thread is still accessing it through another variable that's fine. In the second you may well get a very hard-to-debug memory smash in another module. Free asserts there are no other uses of the referenced object, a much stronger assertion that generally requires much more global knowledge. Clearing variables rarely requires additional complexity in intrfaces. Fully manual memory management often does, since you need to talk about ownership etc. 2. If Junk is really a global variable, then not clearing it usually introduces a BOUNDED leak. The memory will only be retained until the next assignement to Junk. Forgetting the Free in an uncollected system is much more disastrous. (There are cases in which not clearing a variable introduces an unbounded leak. But they're much less common.) -- Hans-Juergen Boehm boehm@mti.sgi.com