From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,fdc38a13551814d,start
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!postnews.google.com!v29g2000hsf.googlegroups.com!not-for-mail
From: Maciej Sobczak <see.my.homepage@gmail.com>
Newsgroups: comp.lang.ada
Subject: Allocators and memory reclamation
Date: Mon, 28 Jan 2008 05:49:35 -0800 (PST)
Organization: http://groups.google.com
Message-ID: 
 <4a2fe64e-ae34-4093-88ec-1dc612a9adbd@v29g2000hsf.googlegroups.com>
NNTP-Posting-Host: 137.138.37.241
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: posting.google.com 1201528175 22238 127.0.0.1 (28 Jan 2008 13:49:35
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Mon, 28 Jan 2008 13:49:35 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: v29g2000hsf.googlegroups.com; posting-host=137.138.37.241;
	posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12)
	Gecko/20071127 Red Hat/1.5.0.12-0.8.el4 Firefox/1.5.0.12
 pango-text,gzip(gfe),gzip(gfe)
Xref: g2news1.google.com comp.lang.ada:19624
Date: 2008-01-28T05:49:35-08:00
List-Id: <comp.lang.ada>

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