Re: Allocators and memory reclamation

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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