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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d02eb5c33ac65d9 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-03-12 11:21:32 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Array and memory usage Date: Wed, 12 Mar 2003 13:18:29 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <1ec946d1.0303100713.7f7bcbb7@posting.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:35261 Date: 2003-03-12T13:18:29-06:00 List-Id: Robert A Duff wrote in message ... >"Randy Brukardt" writes: ... >In other words, I see no reason for this weird "committed" state, where >swap space is allocated on the disk but no physical page is allocated. > >Running out of memory is pretty unpredictable anyway (on virtual systems >like we're talking about), so who cares exactly when it occurs? > >Also, I see no reason why user-mode code needs to be involved at all, >for this trick. There are reasons why user-mode code might want to set >the protection bits of parts of its address space, and handle >traps/signals/whatever caused by accessing those parts, and that >requires separate system calls. I've done that (on both Unix and >Windows). But surely *this* trick (relying on "allocate on first use") >ought to be completely invisible to user-mode code. > >Am I confused, or was the designer of Windwos confused? You want me to explain why Windows is designed the way it is? I think it would be easier for me to find Osama bin Laden.... I can see some benefit to allocating address space which will fault (the uncommited state), and certainly you have to be able to allocate address space which does not fault (the committed state). But why the committed state needs space in the swap file is a mystery to me. ... >> One warning: address space has to be allocated in 64K chunks. If you try >> to use smaller chunks than that, it get rounded up to 64K. (I found that >> out the hard way). > >Why 64K? When not the page size supported by the hardware (which is >2**12 bytes on 386-family). You want me to explain Windows? (Oh, I said that already) Allocations are done in terms of the page size (4K). But, apparently the map of allocated address space has a granularity of 64K. So you rapidly run out of address space if you allocate individual pages. (I know, 'cause that's the way I originally wrote my Storage Pool. The "expanding" stuff was a later addition.) I presume the reason for that is to manage the overhead determine free/in use address space sections. If they use a bitmap, 64K chunks means a 8K bitmap, while 4K pages would a 128K bitmap. Allocating address space is much like calling Malloc; you pass in a size and you get back an address. (I think this similarity was intentional, so malloc could be replaced by VirtualAlloc without much change in the program). And, of course there is a matching VirtualFree. Thus, it's necessary for Windows to keep some data structure of free/allocated address space. >Sorry if this post slightly off topic. At least I'm not ranting about >Adam Smith. ;-) Nah, we're talking about how to design an Ada Storage_Pool for Windows. That's not too off-topic. In any case, it's possible to use this stuff in a Storage_Pool, so you can have your very large array and not require a giant swap file (unless you actually use the array). Since Ada makes access-to-arrays quite painless, it's rather easy to drop such an implementation into existing code that uses a large array. These days, I often just use the array, and switch to a heap/pool implementation if it turns out that it needs to be too large to allocate statically. Randy.