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-Thread: 103376,c68551ab190372c8 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Nick Roberts Newsgroups: comp.lang.ada Subject: Re: Ada memory management? Date: Thu, 07 Oct 2004 18:24:21 +0100 Message-ID: <2slce8F1manqgU1@uni-berlin.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de y49hyiAY15TkBkaoK20YggFPPuQNScXSNIXTxs7sNgfG3gzso= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en In-Reply-To: Xref: g2news1.google.com comp.lang.ada:4884 Date: 2004-10-07T18:24:21+01:00 List-Id: matthias_k wrote: > Hey there, > > since there is an allocator 'new' in Ada, I was wondering if there is a > 'delete' too. I've heard there is a special technique called Storage > Pool in Ada to write own memory managers, but what is the default > deallocator? > > Consider this code: > > procedure Does_This_Leak is > type Int_Ptr is access Integer; > ptr: Int_Ptr; > begin > ptr := new Integer; > end Does_This_Leak; > > Will this procedure leak? Or does Ada somehow deal on its own with the > allocation. There are some Ada implementations where memory never leaks (unless a bug in the compiler or run time system causes one, or the programmer causes it by poor unchecked or external programming). Automatic deallocation combined with comprehensive memory reclamation is called 'full garbage collection'. I think, in reality, there is no native code Ada compiler which supports full garbage collection. Personally, I regret this situation. The compiler vendors all say they don't support full garbage collection because there is no demand, which is true considering the paying Ada compiler market is almost entirely made up of the embedded, real-time, and safety-critical arenas. But the fact that the Ada language is capable of protecting the programmer from the possibility of memory leaks used to be, many years ago, one of the reasons cited for its superiority. The complete lack of support for full garbage collection seems unfortunate to me. It is a proud capability of many languages which have since become far more popular than Ada. I am trying to build my own (open source, GPL) Ada compiler, and I hope to be able to build in full garbage collection support, if only to prove that it can be done. But I do not have recourse to huge resources, so don't hold your breath. http://sourceforge.net/projects/eclat I am a (moderate) fan of full garbage collection, but I concede that it is not, in reality, as useful as you might think. One could guess that 90% of 'desktop' Ada programs would not benefit from the availablity of full garbage collection, for one of the following reasons: the program does little or no dynamic memory allocation; the program does not give any (or much) opportunity for automatic deallocation until (near) the end of program execution; more control over the management of (most) dynamically allocated variables is required; the program must be written to be portable to other Ada compilers (which do not or may not support full garbage collection); the program only uses pre-written encapsulated 'containers' for dynamic data storage, which all do their own memory management anyway. Many programs will only dynamically allocate variables of a fixed size (known at compile time). By having a separate pool for each different size, the necessity for memory reclamation (moving things around) is obviated; only automatic deallocation is useful. I do not know if any existing native code Ada compiler actually supports this technique (doing it automatically). It could be done manually, by implementing one's own storage pool. Probably, full garbage collection would never be used for an embedded or real-time program, because it is a big-memory technique, and does not conform to strict timing requirements. I'm not quite sure about safety-critical programs. However, for the remaining 10% -- or whatever the figure really is -- of desktop programs, full garbage collection would certainly be a useful facility, and I am certain it is why many good programmers often choose languages such as Python, Ruby, and various others which support it, in preference to a language which (in practice) doesn't. -- Nick Roberts