Re: Allocators and memory reclamation

On Mon, 28 Jan 2008 05:49:35 -0800 (PST), Maciej Sobczak wrote:

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?

It does not leak for Deallocate is called. (It would be difficult to
formalize "leaking" otherwise than "for some Allocate there was no
Deallocate called.")

The language does not prescribe the effect of a call to Deallocate on the
program's environment. Note that it might be impossible to return once
allocated system memory back to OS. So taking it naively any program would
leak.

Can I influence this behaviour to portably ensure that memory is
reclaimed when the access type goes out of scope?

Write your own pool, which takes its memory from the standard pool or else
statically.

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?

AFAIK, it is not. Why should it be?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Question about OO programming in Ada
    ... >storage pool does not override Finalize. ... >> procedure Deallocate ... Only if the scope of the access type and the scope of the pool object ...
    (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
    ... 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)