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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,109419a9e4966aaf,start X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newspeer1.nwr.nac.net!newsfeed.freenet.de!newsfeed0.kamp.net!newsfeed.kamp.net!news.osn.de!diablo2.news.osn.de!news.belwue.de!rz.uni-karlsruhe.de!news.rz.uni-karlsruhe.de!not-for-mail From: Florian Liekweg Newsgroups: comp.lang.ada Subject: Heap Memory Management Question(s) Date: Tue, 04 Apr 2006 11:57:00 +0200 Organization: University of Karlsruhe, Germany Message-ID: <443242EC.2060603@gmx.de> NNTP-Posting-Host: i44dyn35.info.uni-karlsruhe.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news2.rz.uni-karlsruhe.de 1144144620 16267 172.22.85.227 (4 Apr 2006 09:57:00 GMT) X-Complaints-To: usenet@rz.uni-karlsruhe.de NNTP-Posting-Date: Tue, 4 Apr 2006 09:57:00 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060305 X-Accept-Language: en-us, en Xref: g2news1.google.com comp.lang.ada:3716 Date: 2006-04-04T11:57:00+02:00 List-Id: Hi, everybody, in the last few days, I've been thumping through the LRMs for both Ada 83 and Ada 95. My primary intrest is to get an overview how heap memory is being used in Ada, and how the language (tries to) support this. I'm also interested to learn how the people who made the language what it is today were reasoning about what feature to provide, and what not to provide. It appears that some features were put in in the hope or expectation that optimizing compilers may be able to make use of them ... First off, I understand that Ada provides both explicit deallocation of heap objects, and garbage collection. Of course, there are static attributes (which stay alive over the whole run of a program), and there are attributes (well, variables) that have a statically determined lifetime (i.e. variables local to a procedure). Now, the LRM for Ada83 defines in \S 3.8 (Access Types), that all objects bound to variables of a particular access type form an implicit collection, and objects belonging to different collections are disjoint (which is actually a nice feature in comparison to e.g. C++, where for every type T, there is only one pointer type, T*, which is visible anywhere in the program, so that any variable "T* foo" can point to any object allocated at any "new T ()" statement, and any class T object can be manipulated anywhere in the program). But is there any way to use this concept for managing the heap memory of the objects of a particular collection? Clearly, given some type T and "type T_ptr is access T", when the definition of T_ptr goes out of scope, there is no way of accessing objects of the collection of T_ptr, so, at first sight, a clever compiler could deallocate these objects. Then again, isn't it possible to have some static (i.e., global) variable of type T_ptr which references a T object while the T_ptr is left momentarily, and until it is entered again? This would imply that the lifetime of T objects belonging to the T_ptr collection is not bracketed by the visibility of the definition of T_ptr. Then, Ada 95 seems to have abandoned the concept of collections entirely --- even the word itself cannot be found neither in the LRM nor in the rationale (except when it refers to "garbage collection"). It also introduces the concept of Storage_Pools which are managed by user-written code, which /could/ be taken to mean that any compiler optimisations that were done on collections were not satisfactory. Is there any truth to that? In general, can any users of commercial, higly optimizing ada compilers report on any optimisations of these compilers that address heap memory objects, and what language features or properties are being exploited to that end? NB, please feel free to PM me; if enough material comes up, I'll post a summary. In that case, please indicate what I can put into the summary, and what you'd like to keep confidential. Yours, Florian