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 Newsgroups: comp.lang.ada Subject: Re: GC in Ada References: <1169636785.504223.139630@j27g2000cwj.googlegroups.com> <45c99c24$1@news.post.ch> <45c9bdb8$1@news.post.ch> <16tzxvuwoo.fsf@hod.lan.m-e-leypold.de> From: Markus E Leypold Organization: N/A Date: Mon, 12 Feb 2007 13:56:43 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:liuybHNXUskfAsdSIV+ORNWdluE= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.204.183 X-Trace: news.arcor-ip.de 1171284686 88.72.204.183 (12 Feb 2007 13:51:26 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:9295 Date: 2007-02-12T13:56:43+01:00 List-Id: Maciej Sobczak writes: > Markus E Leypold wrote: > >>>>> 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. >> This is a 'non sequitur', since it makes sense to say the behaviour >> is >> required to fix certain real time properties. Regardless of wether it >> can be detected in the program (and it could, by observing the wall >> clock). > > Observing the wall clock does not help much in a language where even > null; can raise exceptions. Standard does not even guarantee that any > given sequence of instructions will give consistent timings when run > twice. > > Definitely, observice the wall clock is of no use to verify memory > deallocation, since deallocation might have positive effect on the > timing as well as negative or none at all. If you don't deallocate memory "really" in Unchecked_Deallocation then you aither run out of memory sooner or later (verifiable and it makes sense to require that this doesn't occur) or you have a garbage collector and intermittend garbage collection runs which are visible in the real time behaviour. So it makes sense to say the behaviour (real deallocation to return memory to the free list) is required and checkable, regardless of the question wether _the program_ can verify this. And as I said, from "no legal way for the program to verify" to "doesn't make much sense to say that this behaviour is required" is a non sequitur since behaviour might entail aspects that cannot only be described in the production of data. >>> 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. >> I don't even ask to be shown such an operating system... > > On systems with virtual memory, deallocations that don't span at least > one full page (that condition can be met after joining with other free > blocks, though) will certainly not deallocate anything to the > operating system. Excuse me: I misread "memory reclamation might not be meaningful at all unless the whole program is terminated" as: No memory is ever deallocated. Which is still the only meaningful reading of your sentence since deallocation to the internal free block list is still meaningful and not a no-op. Regards -- Markus