Re: Allocators and memory reclamation

On Jan 28, 8:49 am, Maciej Sobczak <see.my.homep...@xxxxxxxxx> wrote:
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.

Your understanding is incorrect. By default Ada provides deterministic
deallocation only similar to C++, and your program eventually will
crash running out of memory. You may define your own behavior by
deriving from Root_Storage_Pool and assign your own pool
implementation for particular objects.



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?

I would say it is a stretch to say that program above is well-
behaving. What would be bad-behaving then?


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?

that will be irrelevant since default deallocation is deterministic.
You may implement any behavior if use your own pool.


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

.

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