comp.lang.ada
 help / color / mirror / Atom feed
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Subject: Re: Heap Memory Management Question(s)
Date: 04 Apr 2006 11:06:21 -0400
Date: 2006-04-04T11:06:21-04:00	[thread overview]
Message-ID: <wccu099s7ma.fsf@shell01.TheWorld.com> (raw)
In-Reply-To: 443242EC.2060603@gmx.de

Florian Liekweg <liekweg@gmx.de> writes:

> Hi, everybody,
> 
> in the last few days, I've been thumping through the LRMs for both Ada
> 83 and Ada 95.

You might want to take a look at the (draft) Ada 2005 manual,
which is available somewhere on www.adaic.com.

Also, John Barnes' book has a nice discussion of access types and
storage pools and whatnot.

> First off, I understand that Ada provides both explicit deallocation
> of heap objects, and garbage collection.

The designers of Ada 83 apparently expected GC to be supported,
but most compilers do not support GC.  However, I believe you can use
the BDW conservative GC with Ada.

> 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).

"Disjoint collections" sounds like a nice feature, but I think it is
hardly ever useful.  Usually, one declares a single access type for each
designated type.  Having a name for it is just a nuisance -- the C way
is preferable in this regard.  Ada 2005 allows anonymous access types
almost anywhere -- "Foo: access T;" is sort of like "T* foo" in C.

In Ada 83, access types could only point at heap objects.
Ada 95 added "access all", which allows pointing at declared
objects, and allows conversion from any other access type
with the right designated type -- i.e. crossing collections.

I removed the term "collection" from the Ada 95 RM, because I didn't
think it was all that useful.  But the concept is still there -- access
types without the "all" behave as in Ada 83.

> 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.

Some compilers do that.  Most do not.  I don't think it's a good idea,
especially now that we have storage pools.  In my experience,
approximately zero access types are nested inside procedures
anyway.

>...  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?

No.  In Ada 83, if T_Ptr is local to a procedure, it's not visible
outside, so you can't declare variables of that type outside.
In Ada 95, you can use general access types (the "access all" kind) to
create such dangling pointers.  However, you have to say
'Unchecked_Access to do so, which makes it harder to do by accident.
You can use finalization to clean up such potentially-dangling
pointers.

I'm not sure what you mean by "left momentarily", but you can't create a
pointer to a local collection, return from the procedure, then reenter
the procedure and expect it to point to the same thing!  If you
dereference a dangling pointer, your program will behave in an
unpredictable manner.

>...  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.

The lifetime of a local collection is local.

> 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?

I suppose you could put it that way.  There are hundreds of reasonable
ways of managing heap memory, none of which is best for all purposes.
Therefore, whatever method the compiler provides will not be
best for some programs.  That's why we added storage pools -- the user
can then define the heap-management strategy.  They can deallocate
objects en masse when leaving a procedure, if that's appropriate.
Most programs can just use the default storage pool provided
by the compiler.

- Bob



  reply	other threads:[~2006-04-04 15:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-04  9:57 Heap Memory Management Question(s) Florian Liekweg
2006-04-04 15:06 ` Robert A Duff [this message]
2006-04-05 10:51   ` Florian Liekweg
2006-04-05 16:50     ` jimmaureenrogers
2006-04-05 21:42     ` Robert A Duff
2006-04-06  0:17     ` Adam Beneschan
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox