Prev: ANN: GNAT/GPL Solaris 10: 2007-solaris-x86
Next: Concurrency and interfaces
From: Maciej Sobczak on 28 Jan 2008 08:49
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. This is at least what I can observe with controlled
types.

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?
Can I influence this behaviour to portably ensure that memory is
reclaimed when the access type goes out of scope?

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?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
From: gpriv on 28 Jan 2008 09:52
On Jan 28, 8:49 am, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote:
> 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. This is at least what I can observe with controlled
> types.

Your understanding is incorrect. By default Ada provides deterministic
deallocation only similar to C++, and your program eventually will
crash running out of memory. You may define your own behavior by
deriving from Root_Storage_Pool and assign your own pool
implementation for particular objects.


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

I would say it is a stretch to say that program above is well-
behaving. What would be bad-behaving then?


> Can I influence this behaviour to portably ensure that memory is
> reclaimed when the access type goes out of scope?
>
> 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?

that will be irrelevant since default deallocation is deterministic.
You may implement any behavior if use your own pool.

>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com

From: Lucretia on 28 Jan 2008 09:53
On Jan 28, 1:49 pm, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote:

> "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."

I didn't realise this either.

Luke.
From: Dmitry A. Kazakov on 28 Jan 2008 10:15
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
From: gpriv on 28 Jan 2008 11:00
On Jan 28, 9:53 am, Lucretia <lucret...(a)lycos.co.uk> wrote:
> On Jan 28, 1:49 pm, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote:
>
> > "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."
>
> I didn't realise this either.
>
> Luke.

I think what they mean here is as one allocates memory it will be
requested on the system level. This memory might be only released when
all objects are properly deallocated from the entire pool. However it
seems to be recommendation ("might") and is not what I see with GNAT.
I see memory footprint growing and shrinking as it runs and it is
never deallocating all dynamic objects at any time.

George

 |  Next  |  Last
Pages: 1 2 3
Prev: ANN: GNAT/GPL Solaris 10: 2007-solaris-x86
Next: Concurrency and interfaces