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.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,fdc38a13551814d
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Allocators and memory reclamation
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: 
 <4a2fe64e-ae34-4093-88ec-1dc612a9adbd@v29g2000hsf.googlegroups.com>
Date: Mon, 28 Jan 2008 16:15:27 +0100
Message-ID: <lneim0ua86uj$.5q4owyndn3kj$.dlg@40tude.net>
NNTP-Posting-Date: 28 Jan 2008 16:15:27 CET
NNTP-Posting-Host: edd4e41a.newsspool1.arcor-online.net
X-Trace: 
 DXC=\i6j^:Vnf_ag`45cDR8l?oic==]BZ:afn4Fo<]lROoRaFl8W>\BH3YbZgl2iY_Ul:bDNcfSJ;bb[eFCTGGVUmh?dLK[5LiR>kgbFE=bchO>2mk
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:19627
Date: 2008-01-28T16:15:27+01:00
List-Id: <comp.lang.ada>

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