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,be7fa91648ac3f12 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!newscon02.news.prodigy.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Large arrays (again), problem case for GNAT Date: 14 Apr 2005 11:18:22 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1113491902 26978 192.74.137.71 (14 Apr 2005 15:18:22 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 14 Apr 2005 15:18:22 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:10463 Date: 2005-04-14T11:18:22-04:00 List-Id: "Alexander E. Kopilovich" writes: > Robert A Duff wrote; > > > "(see below)" writes: > > > > > I see that Adrian is using Linux. > > > Is Linux not notorious for problems of this kind? > > > > > > I seem to remember that it has some kind of optimistic allocator > > that can grant a memory allocation request, only for it to fail > > when you try to use the memory you appear to have been granted. > > > >... > > > > I'm not sure why you say "notorious". It seems to me that > > allocate-on-write is desirable. > > So, what is the meaning of malloc call with this approach? In which court > (somewhere in Linux or outside) I should defend my right to use the memory, > which I legally requested by malloc, was granted, and then deprived of it? You have no such right! ;-) You've allocated address space, and it's perfectly legitimate (according to the Ada RM, and according to Linux docs) for the system to run out of memory when you touch it. I admit that it would be easier to program if you could isolate the Storage_Error to the allocation point, presuming you want to handle Storage_Error and recover somehow. But Storage_Error is pretty broken in Ada anyway. It's practically impossible to write a formally correct handler for this exception. AARM-11.1 says: 6 The execution of any construct raises Storage_Error if there is insufficient storage for that execution. The amount of storage needed for the execution of constructs is unspecified. 6.a Ramification: Note that any execution whatsoever can raise Storage_Error. This allows much implementation freedom in storage management. The reason I like allocate-on-write is that it is very useful to allocate a huge array, and then only use some part of it. That way, the program can deal with enormous input data, without paying the cost when the input data is small. Physical memory is 1000 times more expensive than address space. Does anybody here know how to get allocate-on-write under MS Windows? But I admit it would be useful to be able to turn off allocate-on-write for particular objects. Somebody posted a note telling how to do that on Linux, but unfortunately it's apparently global to the whole system, which just isn't good enough, in my opinion. You could achieve that by touching every page, but it's not portable: the Ada manual doesn't guarantee anything about that, and you have to know the page size and understand the underlying OS behavior. I can imagine a system where touching every page does not necessarily allocate physical memory. The original example that started this thread *did* touch every page; it's a mystery to me why this didn't work. - Bob