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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,13d6cd0af0d0d769 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-03-24 04:29:30 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!stern.fokus.gmd.de!ceres.fokus.gmd.de!zib-berlin.de!news.mathworks.com!uunet!psinntp!ss3!ss5!mjmeie From: mjmeie@ss5.magec.com (Mike Meier) Subject: Re: Does memory leak? Message-ID: Sender: usenet@ss3.magec.com Nntp-Posting-Host: ss5 Organization: Magnavox Electronics Systems Company X-Newsreader: TIN [version 1.2 PL2] References: <3kopao$ekg@nef.ens.fr> Date: Fri, 24 Mar 1995 12:29:30 GMT Date: 1995-03-24T12:29:30+00:00 List-Id: Duncan Sands (sands@clipper.ens.fr) wrote: : Does Ada leak memory? I would like to believe it doesn't, but : how does it manage not to (without having to use unchecked : deallocation)? : For example, if I have a pointer to a block of memory, and I set : that pointer to null, in simple cases I am ready to believe that : the compiler knows I'm finished with the block... but if the : pointer is to a complicated self-referential structure, some sort : of black magic seems needed to work out whether I'm really : finished with that structure or not. Can this truly be done : efficiently? No, Ada doesn't leak memory. But, some Ada programs (especially those using C-language X-windows code ;-)) leak memory like a sieve. In current reality, no Ada run-time environments that I'm aware of provide automated garbage collection (unless you count deallocation of objects that fall out of scope), including mainly Alsys and Rational/Verdix. There have been -long- threads on this subject in this newsgroup in the not too distant past, and the general consensus seemed to be that garbage collection will probably not exist in the Ada world soon. So what do you do? You make sure that you deallocate all dynamically allocated objects as soon as you're done with them. If the object is a nested structure containing other dynamically allocated objects, you deallocate the nested structures first. The simplest way we found to do this was to modify the Booch components that we use for almost all dynamic data structures to take care of this automagically. Of course, in Ada 83 this takes some special tweaking to properly nested data structures containing private or limited private types. If you want to be able to determine what data structures are leaking, you must add a few generic parameters to identify the owner (and any limits you want to place on the data structure for performance purposes). We even added a dump facility to print out to a file the memory usage of each data structure within a process on demand. Believe it or not, none of this adds all that much overhead to the average data structure manipulation. Sure would be nice to have some of these features in the Ada 95 Booch Components by the time we use them (1996 or 1997 maybe). But, I digress greatly. I hope that I gave you a useful reply somewhere in there.