Re: Large arrays (again), problem case for GNAT

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccbr8h4c0f.fsf@shell01.TheWorld.com...
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>
> > Does anybody here know how to get allocate-on-write under MS Windows?
>
> Just to be clear: Windows does not allocate physical memory on
> allocation, but it does allocate backing store in the page file.
> And the page file is limited to 4GB, which isn't all that big
> these days.  Does anybody know how to tell Windows not to
> allocate backing store?
>
> I want to write a Storage_Pool, which allocates an array of (say)
> hundreds of megabytes, and allocate little pieces out of that giant
> array.  I want to be *able* to use all those hundreds of megabytes, but
> I don't want to allocate space in the paging file unless they're
> needed.  This works by default on most Unices, but not on Windows.

You can do something like that with the actual memory management functions
of Windows, which separately allocate and commit pages. (Commit uses the
backing store.) But you get a trap if the pages aren't commited and are
touched.

I have a storage pool that sort of works this way. It was intended to allow
allocating virtual space for large arrays, and then expand them as needed
with committed memory. Warning: although Windows uses 4K pages, address
space management allocation is done in 64K chunks. Ask for 1 byte, and you
get one byte, and the other 63.9K is lost to all other use. My pool expands
the arrays by rewriting the dope of the arrays passed into the functions -
something that no one should ever do unless they're the author of the
compiler. And probably not even then.

I'll e-mail to it you.

                     Randy.