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,21960280f1d61e84
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news2.google.com!news.germany.com!solnet.ch!solnet.ch!news-zh.switch.ch!switch.ch!cernne03.cern.ch!not-for-mail
From: Maciej Sobczak <no.spam@no.spam.com>
Newsgroups: comp.lang.ada
Subject: Re: GC in Ada
Date: Fri, 09 Feb 2007 15:20:13 +0100
Organization: CERN News
Message-ID: <eqhvuu$uh6$1@cernne03.cern.ch>
References: <1169636785.504223.139630@j27g2000cwj.googlegroups.com>
 <m7ejpj5u9t.fsf@hod.lan.m-e-leypold.de> <u7iv8o16m.fsf@stephe-leake.org>
 <3pejpgfbki.fsf@hod.lan.m-e-leypold.de> <epkcru$fk2$1@cernne03.cern.ch>
 <njirepncb0.fsf@hod.lan.m-e-leypold.de> <eppn6r$m41$1@cernne03.cern.ch>
 <vwbqkffq94.fsf@hod.lan.m-e-leypold.de> <eputhf$p8u$1@cernne03.cern.ch>
 <dzsldoachu.fsf@hod.lan.m-e-leypold.de> <eq6v5b$bsb$1@cernne03.cern.ch>
 <l5iregra8a.fsf@hod.lan.m-e-leypold.de> <eq9gv3$dre$1@cernne03.cern.ch>
 <il64aftsq7.fsf@hod.lan.m-e-leypold.de> <eqa2j8$mfu$1@cernne03.cern.ch>
 <bpveifcmum.fsf@hod.lan.m-e-leypold.de> <eqc456$fp5$1@cernne03.cern.ch>
 <45c99c24$1@news.post.ch> <eqccdc$k89$1@cernne03.cern.ch>
 <45c9bdb8$1@news.post.ch> <eqekkj$hq1$1@cernne03.cern.ch>
 <n44ppxvy2n.fsf@hod.lan.m-e-leypold.de>
NNTP-Posting-Host: abpc10883.cern.ch
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: cernne03.cern.ch 1171030814 31270 137.138.37.241 (9 Feb 2007 14:20:14
 GMT)
X-Complaints-To: news@@cern.ch
NNTP-Posting-Date: Fri, 9 Feb 2007 14:20:14 +0000 (UTC)
User-Agent: Thunderbird 1.5.0.9 (X11/20061220)
In-Reply-To: <n44ppxvy2n.fsf@hod.lan.m-e-leypold.de>
Xref: g2news2.google.com comp.lang.ada:9196
Date: 2007-02-09T15:20:13+01:00
List-Id: <comp.lang.ada>

Markus E Leypold wrote:

>>> And Unchecked_Deallocation should deallocate even when a collector
>>> is present.
>> I don't understand. There is no legal way for the program to verify
>> that anything was indeed deallocated, so it doesn't make much sense to
>> say that this behaviour is required.
> 
> Oh yes. Deallocating immeditately and deallocating later makes a
> difference in time and space behaviour -- which IS measurable outside
> the program

With a small issues that this possibility is not formalized by the 
language standard (please read carefully my sentence above: "there is no 
*legal* way *for the program*").

And that is why it is *not* measurable, because there is no sensible way 
to define at which level of memory management it should be measured.

As was already pointed out in this thread, with some operating systems 
memory reclamation might not be meaningful at all unless the whole 
program is terminated.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/