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!news4.google.com!news2.google.com!newsread.com!news-xfer.newsread.com!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!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 17:19:31 -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 1113513571 30418 192.74.137.71 (14 Apr 2005 21:19:31 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 14 Apr 2005 21:19:31 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:10477 Date: 2005-04-14T17:19:31-04:00 List-Id: "Dmitry A. Kazakov" writes: > On 14 Apr 2005 11:18:22 -0400, Robert A Duff wrote: > > > 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. > > I think this approach is flawed. The contract of malloc is to return memory > not the address space. Well, I'm not an expert on malloc. Where is it documented that this is the contract? Apparently the Linux folks don't think that's the contract. I *am* an expert on Ada, and I know that "new" does not necessarily reserve real memory -- it might just reserve address space. >...That must be just another system call. I agree that there *should* be two separate calls: one reserves address space, and the other reserves real memory. Or one call with a Boolean parameter. > Consider an application that needs contiguous address space. User storage > pool is an excellent example. The application must request the space from > OS telling something like: "reserve me 100GB and allocate n bytes starting > from the first address." After that it could allocate memory *within* that > space by pieces as needed. For this it would simply use realloc instead of > malloc. No, I don't want to do realloc or anything like that. I just want it to allocate physical memory (and backing store) when I write upon that memory. Apparently, malloc on Linux is exactly the "reserve me 100GB and allocate n bytes starting from the first address" primitive, except there's no need for the "allocate n bytes starting from the first address" part. And it does exactly what I want in the storage-pool example. I understand that other examples would prefer to prevent Storage_Error happening willy-nilly all over the place. Ada does not provide that semantics, and apparently Linux does not either, unless you set some global flag. >... No need to break contracts. I don't think Linux (or GNAT upon Linux) is breaking any contract. You just don't like what the contract defines! Fair enough. - Bob P.S. Nobody has challenged my remark that Storage_Error handlers are impossible. ;-)