Re: Memory management clarification

[Maciej Sobczak <no.spam@no.spam.com>]

Robert A Duff wrote:

> If you use the default storage pool(s), the language standard does not
> specify when heap memory is reclaimed.  Most implementations do not
> reclaim any such memory unless you explicitly call
> Unchecked_Deallocation.

OK.

> If you put "for T'Storage_Size use 1_000_000;", then implementations
> should reclaim all memory allocated for type T when the scope of T is
> left.

Nice. Why putting this arbitrary limit?

And what does it mean, anyway - is the pool actually pre-allocated with 
this size when the for..use... statement is executed, or does it start 
empty and later "inflates" as necessary, but no bigger than the given limit?
The difference is not only the observable memory consumption (even when 
not the whole pool is used), but also the possibility and timing of 
low-memory errors.

> This is not
> a very useful capability, because most access types need to be at
> library level, so the memory won't be reclaimed until the whole program
> is done.

Indeed, not really useful.

> You should look up user defined storage pools.  You can say:
> 
>     for T'Storage_Pool use My_Pool;
> 
> and then you can control when memory will be reclaimed.
> You can reclaim all memory in My_Pool whenever you like -- but
> beware dangling pointers.

I have to beware them when using Unchecked_Deallocation as well. :)


>>2.
>>
>>loop
>>    declare
>>       X : MyTypeRef;
>>    begin
>>       X := new MyType;
>>    end;
>>end loop;
>>
>>What now? Is this any different from the memory management point of view?
> 
> No.  X.all will never be reclaimed (on most implementations).  The only
> difference here is that you're allocating only one object.

Not really - there's a loop.
I understand that the code above leaks memory, just like my first example.


> Suppose we added a call P(X) inside the begin/end.  And suppose P saves
> X in a global variable.  The implementation cannot deallocate the memory
> X points to, because that would leave a dangling pointer in the global
> variable.

Right, but I was interested exactly in the case where there is just one 
reference and it is trivial for the compiler to prove that the object is 
not aliased. But without GC there's no difference anyway.


>>4.
>>
>>Is it possible to associate some function with object allocated by new,
>>which would be called at the time (or maybe after) the object is
>>reclaimed?
>>Yes, I'm asking about destructors or finalizers.
> 
> Yes.  Look up "controlled types".  These allow you to associate a
> Finalize operation with a type.  For local variables, Finalize will be
> automatically called when the procedure is left.

Good - this, basically, should allow me to implement some form of local 
resource manager (in C++ this idiom is called RAII) that will deallocate 
the object (or any other resource) when the scope is left.

> For heap objects,
> Finalize will be called when you do Unchecked_Deallocation (or, if you
> never do U_D, when the program is done).

Fine. Is the order of calling finalizers well-defined for the latter case?


Thank you for these explanations,

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/