Re: Allocators and memory reclamation

[gpriv@axonx.com]

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