Re: newbie Q: storage management

["Samuel A. Mize" <smize@magellan.bgm.link.com>]

Kaz Kylheku wrote:
> 
> I've looked at the ISO standard and the relevant FAQ's and tutorials, but I
> still need some discussion or clarification about the management of objects
> obtained via ``new'', because what I have read so far seemed rather vague in
> one respect.
> 
> Whose responsibility is it to destroy these objects? The Ada 95 standard
> says that an implementation is permitted to implement garbage collection,
> but not required to do so.

It's the programmer's responsibility to destroy individual objects with
Unchecked_Deallocation.

What this does is implementation dependent -- if memory reclamation is required,
it's the responsibility of the programmer (or code reuser) to ensure that the
implementation (that is, by the compiler and run-time system) reclaims memory
as necessary.


> I know that it is possible to instantiate a generic freeing function for
> explicitly destroying objects. But why is there is this lack of symmetry in the
> language?  On the one hand, you have a slick ``new''-expression to create
> objects, but the complementary deletion operation is totally obscured.

The language designers did not want to require memory reclamation, let alone
garbage collection, because there are important application domains where these
are avoided.  Many embedded systems builders avoid using dynamic memory, and the
needs of such developers were a major design driver for Ada.

If reclamation were in the language, embedded systems builders could just avoid
it, but compilers targeted to the embedded-system market would still have to
include it to be validated.  This adds cost and complexity to the compiler,
and adds size to the run-time code that gets loaded along with the user code.

(Embedded systems avoid dynamic memory because a real-time critical system, like
a terrain-following radar, can't afford to pause for half a second to collect
garbage, let alone fail because it ran out of memory.)


>Does
> this mean that explicit freeing of objects via an instance of
> Unchecked_Deallocation is discouraged (due to the potential creation of
> dangling references)?

No.  It just means you should know what you're doing in two areas:
1) Make sure the logic of your code avoids using dangling references.
2) If memory reclamation is important for your application, make sure that
   the implementation supports it.
3) If your program is large or long-lived enough for memory leakage to be
   a problem, make sure you deallocate objects when done with them.  (In
   this case, (2) definitely applies.)


Note that dynamic storage is often useful WITHOUT reclamation.  For instance,
if you read some kind of dictionary into your program from a file, you might
put it into a linked list so you aren't tied to a specific table size, even
though you will never delete any of the terms.


>Is it the reponsibility of the language implementation to
> automagically detect when an object is no longer reachable and do the
> appropriate deallocation, even if garbage is not collected?

Nope.  You can chew up the entire system's memory with this program:

  procedure Just_Kill_Me is
    type integer_access is access integer;
    x: integer_access;
  begin
    loop
       x := new integer;
    end loop;
  end Just_Kill_Me;

Is this the best language-design tradeoff?  well, yes and no, respectively.
It depends on what you want to use the language for, and how you want to
use it.

Sam Mize

-- Samuel Mize           (817) 619-8622               "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005