Allocators and memory reclamation

Hi,

Consider the following:

procedure Foo is
type Int_Ptr is access Integer;
P : Int_Ptr;
begin
P := new Integer;
P := new Integer;
P := new Integer;
end Foo;

procedure Main is
begin
loop
Foo;
end loop;
end Main;

In Foo above, three objects of type Integer are allocated and the
storage is taken from the storage pool associated with the Int_Ptr
access type.
What I understood before is that this storage pool is torn down when
the access type itself goes out of scope and it is also when the
memory is reclaimed. As a result no memory is leaked in the above code
- I can call Foo as many times as I want without any risk of running
out of memory. This is at least what I can observe with controlled
types.

The problem is that my understanding conflicts with what I've just
found in AARM (13.11):
"By default, the implementation might choose to have a single global
storage pool, which is used (by default) by all access types, which
might mean that storage is reclaimed automatically only upon partition
completion."

This means that the implementation might turn the above well-behaving
procedure into a memory leak. Is this correct?
Can I influence this behaviour to portably ensure that memory is
reclaimed when the access type goes out of scope?

Another question relates to the order of finalizing objects. If the
storage pool is torn down when the access type goes out of scope, is
the order of finalizing objects guaranteed?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
.

Relevant Pages

  • Re: Allocators and memory reclamation
    ... procedure Foo is ... storage is taken from the storage pool associated with the Int_Ptr ... the access type itself goes out of scope and it is also when the ... As a result no memory is leaked in the above code ...
    (comp.lang.ada)
  • Re: Allocators and memory reclamation
    ... storage is taken from the storage pool associated with the Int_Ptr ... the access type itself goes out of scope and it is also when the ... As a result no memory is leaked in the above code ...
    (comp.lang.ada)
  • Re: put of access type
    ... implemented as a reference to some storage pool and an offset into ... storage pool returns an System.Address. ... the compiler generated code to implement .all and to implement ... conversions to anonymous access type is not going to take that into ...
    (comp.lang.ada)
  • Re: put of access type
    ... relevant language change is that you can convert from pool-specific to ... or whatever a general access type is represented as. ... The compiler can't make the conversion, ... access types having a well-defined storage pool. ...
    (comp.lang.ada)
  • Re: Allocators and memory reclamation
    ... storage is taken from the storage pool associated with the Int_Ptr ... the access type itself goes out of scope and it is also when the ... and reclaim the memory, but it is not required to. ... Finalization of heap objects has nothing to do with storage pools. ...
    (comp.lang.ada)