Re: Allocators and memory reclamation
- From: Robert A Duff <bobduff@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 28 Jan 2008 19:41:58 -0500
Maciej Sobczak <see.my.homepage@xxxxxxxxx> writes:
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.
Some implementations might behave that way, but you should not rely on
it.
...This is at least what I can observe with controlled
types.
I don't understand what you mean about controlled types.
There are none in the above example, and I don't know
what example you have in mind.
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."
The implementation is allowed to use a local pool for Int_Ptr,
and reclaim the memory, but it is not required to. I think
most implementations use a global pool by default. That's
certainly the case with GNAT.
To force the reclamation, you can say:
for Int_Ptr'Storage_Size use 1000; -- or some number
or:
for Int_Ptr'Storage_Pool use My_Pool;
where My_Pool gets reclaimed somehow (that's up to you).
My_Pool might allocate its data on the stack, so it will
be reclaimed. Or it might allocate its data on the global
heap, and have a Finalize that reclaims it. Or some of
each.
I think implementations should not do such reclamation by default -- a
global heap is a better default way to do things.
This means that the implementation might turn the above well-behaving
procedure into a memory leak. Is this correct?
Well, yeah, but that's a strange way to put it. The above procedure
is not well behaved, unless you are relying on some non-portable
implementation-depdendent behavior.
Can I influence this behaviour to portably ensure that memory is
reclaimed when the access type goes out of scope?
Yes.
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?
Finalization of heap objects happens when you do
Unchecked_Deallocation. In addition, when an access type goes
out of scope, all remaining objects (the ones you did not
Unchecked_Deallocate) are finalized in an arbitrary order,
but this does not free the memory.
Finalization of heap objects has nothing to do with storage pools.
It has to do with where the access type is declared,
not when its pool is finalized.
In implementation terms, each finalizable heap object is
chained onto a doubly-linked list. U_D removes the object
from the list, finalizes it, and frees the memory.
When the access type goes out of scope, the implementation
walks down the list and finalizes everything on it.
There is one list per access type.
Many variations of this scheme are possible, of course.
- Bob
.
- Follow-Ups:
- Re: Allocators and memory reclamation
- From: Maciej Sobczak
- Re: Allocators and memory reclamation
- References:
- Allocators and memory reclamation
- From: Maciej Sobczak
- Allocators and memory reclamation
- Prev by Date: Re: Allocators and memory reclamation
- Next by Date: Re: ANN: GNAT/GPL Solaris 10: 2007-solaris-x86
- Previous by thread: Re: Allocators and memory reclamation
- Next by thread: Re: Allocators and memory reclamation
- Index(es):
Relevant Pages
|
