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:21:04 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!news.rwth-aachen.de!news.rhrz.uni-bonn.de!news.uni-stuttgart.de!rz.uni-karlsruhe.de!xlink.net!howland.reston.ans.net!gatech!news-feed-1.peachnet.edu!news.duke.edu!news.mathworks.com!bigboote.WPI.EDU!noc.near.net!inmet!spock!stt From: stt@spock.camb.inmet.com (Tucker Taft) Subject: Re: Does memory leak? Message-ID: Sender: news@inmet.camb.inmet.com Organization: Intermetrics, Inc. X-Newsreader: TIN [version 1.1 PL8] References: <3kopao$ekg@nef.ens.fr> Date: Thu, 23 Mar 1995 22:38:13 GMT Date: 1995-03-23T22:38:13+00:00 List-Id: Duncan Sands (sands@clipper.ens.fr) wrote: : Does Ada leak memory? No, but some implementations do ;-). : ...I would like to believe it doesn't, but : how does it manage not to (without having to use unchecked : deallocation)? Implementations of Ada are allowed to support automatic storage reclamation (garbage collection) of storage allocated using "allocators" (such as "new T") but few if any do so at this point. Implementations of Ada are expected to automatically reclaim storage for local variables, even variables whose size is not known at compile-time. This is often accomplished by using a special mark/release heap (aka "secondary stack") for such local variables. Note that Ada is more like C++ than Eiffel/Smalltalk in its overall approach, since objects are by-default stack resident rather than heap-resident. In Smalltalk, pretty much everything lives on the heap, and garbage collection is essential. (In Eiffel you can have "expanded" objects which can be implemented as stack-resident objects, though the default remains non-expanded, heap-resident objects.) In Ada, you can write very large programs that never use allocators or the heap. This "heap-free" approach will not work as well in conjunction with Ada 95's "class-wide" types, but explicit recycling of those objects that do need to be heap-resident can minimize the need for automatic garbage collection. This approach is practical because not everything is on the heap -- only what needs to be is. In Ada 95, users can implement their own storage "pools" which could be used to provide some degree of automatic storage reclamation for heap objects. In any case, most users of Ada who do use allocators, also use Unchecked_Deallocation, which is analogous to "free" of malloc/free fame. ("Free" sounds better than Unchecked_Deallocation, but it is really the same thing.) Some Ada users use explicit mark/release, which is typically much faster, presuming it matches your application needs. I would expect more use of mark/release in Ada 95 now that users can implement their own storage pools. The other relevant new features of Ada 95 are user-defined assignment and finalization, which are analagous to C++ copy constructors and destructors. These allow the programmer to get control when copies are made, or when an object goes out of scope. These can be used to implement automatic reference-counting-based management of dynamic storage, which can do the job adequately for certain applications. : 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? Most (all?) current Ada compilers do not provide garbage collection. Hence setting a pointer to null will not cause any automatic storage reclamation in such implementations. Now that general purpose (though some will say potentially "dangerous") language-independent "conservative" garbage collectors are available, I would expect more of them will be integrated with Ada implementations. True "exact" garbage collection can also be implemented in Ada, but thus far the market demand for it has not matched the expense of implementation. It may be that the GNU Modula-3 "exact" garbage collection support could be adapted to work with the GNU NYU Ada 95 compiler (GNAT). : You can see that I know nothing about how garbage collection works, : and precious little about what Ada requires for memory management. : I suspect I'm not the only one. If someone could demystify all this : for me, I would be very grateful... I hope the above helps a little. The topic of storage management, and the various religious and technical battles associated therewith, can expand to fill whatever amount of time you have available, so beware... : Thanks a lot, : Duncan Sands. -Tucker Taft stt@inmet.com Intermetrics, Inc.