Re: Allocators and memory reclamation

On Mon, 28 Jan 2008 14:27:23 -0800 (PST), Maciej Sobczak wrote:

I'm interested in the pattern of calls to Deallocate in the given
program.
My understanding, initially, was that Deallocate is called kind of
implicitly when the storage pool is torn down together with its
associated access type.
It does not seem to be the case, but the storage pool itself can keep
track of the allocated blocks and at the end do "something" with them.

In my understanding Deallocate is just not called. One can enforce this
behavior when there is GC by applying the pragma Controlled, but not the
reverse.

The interesting part is that finalizers of My_Type were called and
this is even before the pool gets finalized itself (I've checked it by
overriding Finalize for My_Pool_Type). This is good, because after
that only raw memory remained to be reclaimed.
The question is - who called the finalizers of allocated objects? Any
AARM paragraphs for this would be welcome.

There is a linked list of controlled objects allocated in the access type
scope.

I don't think this is "good". The language should be consistent in its
choices, if the design choice was to leak memory, then it finalization must
leak as well! (:-))

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?

Why not? :-)

If not, then there is additional (automatic) question: how can I make
it guaranteed?

Again, what for? (:-)) A properly designed program should never rely on
such stuff. I mean either there should be a GC with the properties defined,
and BTW, no GC usually tells anything about not only in which order but
also when and if something gets collected; or else it should do absolutely
nothing.

There is a related problem which I've found while playing with the
above code example: I cannot have a pointer to the standard pool.
In other words, this:

type Pool_Ptr is access Root_Storage_Pool'Class;
PP : Pool_Ptr := Integer'Storage_Pool'Access;

is not possible, because the standard storage pool is not aliased.
How can I get a reference to the standard pool so that I don't have to
repeat the "Integer'Storage_Pool" million times?

What about this:

P : Root_Storage_Pool'Class := Integer_Ptr'Storage_Pool;

type Integer_Ptr is access Integer;
P : Root_Storage_Pool'Class renames Integer_Ptr'Storage_Pool;

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