Heap Memory Management Question(s)

[Florian Liekweg <liekweg@gmx.de>]

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