Re: Allocators and memory reclamation

Maciej Sobczak wrote:

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.

This is implementation dependent. The storage pool may or may not be more global than the type.

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

Correct. "Might" means that an implementation may choose either way; the implementation you used for your test above does not seem to use a single, global storage pool.

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?

Whether or not your test program is "well behaved" depends on the compiler you use. For the specific behavior you desire, you must define your own storage pool for the type, or somehow ensure that all access values are deallocated (such as through controlled types).

--
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail
17
.

Relevant Pages

  • 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: 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)
  • 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)