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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,419864ed91cc937d
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news1.google.com!postnews.google.com!h19g2000yqb.googlegroups.com!not-for-mail
From: Cyrille <comar@eu.adacore.com>
Newsgroups: comp.lang.ada
Subject: Re: heap size exceeded for large matrices
Date: Mon, 30 Aug 2010 04:04:28 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: 
 <8c2e3800-9f6b-4a16-a8a6-e0aa9eeb13fe@h19g2000yqb.googlegroups.com>
References: 
 <14007b1b-c290-4c73-a0ec-d3c5195b83d4@t20g2000yqa.googlegroups.com>
 <4c7a360b$0$10227$ba4acef3@reader.news.orange.fr>
 <g9tk76ljou9a3in805jes6n6pg4oqtcna6@4ax.com>
 <340c87af-1f15-4590-baa9-ec7e864b7048@l20g2000yqm.googlegroups.com>
 <4c7ada3c$0$2372$4d3efbfe@news.sover.net>
 <7bol761eas8q6evpsar3kbu57fnihm7q3k@4ax.com>
 <k6vm769bcgllh2lg4g373dvfo25q8bu7m8@4ax.com>
NNTP-Posting-Host: 212.99.106.125
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1283166272 4739 127.0.0.1 (30 Aug 2010 11:04:32
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Mon, 30 Aug 2010 11:04:32 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: h19g2000yqb.googlegroups.com; posting-host=212.99.106.125;
 posting-account=bNhsVwoAAAB6XmNPWgYcbUm6npIwL2C4
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8)
 Gecko/20100722 Firefox/3.6.8 ( .NET CLR 3.5.30729),gzip(gfe)
Xref: g2news1.google.com comp.lang.ada:13847
Date: 2010-08-30T04:04:28-07:00
List-Id: <comp.lang.ada>

On Aug 30, 11:45=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:>
> Apologies to all: My late night recollection was faulty; my experiment co=
vered a
> different case.
>
> If the "new" allocation is in a loop, explicit deallocation (or possibly
> controlled types - I haven't tried them yet) is required.

If you want this behavior (i.e. deallocation of your dynamically
allocated object on scope exit) you can explicitly associate the local
access type to a pool object of type
System.Pool_Local.Unbounded_Reclaim_Pool.