Reason for cygwin GCC 2.97 non-bootstrap found

[Christopher Faylor]

On Mon, Nov 20, 2000 at 06:29:47PM -0800, Zack Weinberg wrote:
>> >I am not familiar with Cygwin internals either.  However, the
>> >underlying Windows primitives - MapViewOfFile, UnmapViewOfFile - do
>> >not appear to support allocating a large chunk of memory and then
>> >freeing bits and pieces of it, which is what the above winds up
>> >doing.  (I am basing this on a rapid skim of the Windows API docs
>> >available, with effort, from msdn.microsoft.com.  I may be wrong.)
>> 
>> I think that this use should be supported.  UnmapViewOfFile doesn't seem
>> to be too picky about what it is releasing.  I've seen it unmap part of
>> the text segment, for instance.
>> 
>> If mmap is broken, then we'll certainly fix it.  It sounds like it should
>> be easy to duplicate the breakage from your description.
>
>The doc page I'm looking at
>( http://msdn.microsoft.com/library/psdk/winbase/filemap_9011.htm ) says
>UnmapViewOfFile takes only one argument, which is the base of a region
>previously mapped by MapViewOfFile, and blows away the entire thing.

Oops.  You're right.  I had been working with this stuff quite recently
so, of course, I was "sure" how this worked.  If UnmapViewOfFile doesn't
accept a second argument, there is not much that can be done unless it
is possible to do something similar with VirtualProtect.

>> Reading what xvalloc.c does, I think it makes sense to use cygwin's heap
>> to allocate the memory, just to avoid having one implementation trip
>> over another.  We could easily provide either valloc or memalign, if
>> needed.  I'm sort of suprised that this isn't available now, in fact.
>> 
>> Is there any reason not to just use cygwin's heap?
>
>At present, if xvalloc.c detects both mmap and valloc/memalign, it
>uses mmap; this is because a common implementation of valloc wastes
>one page per allocation.  Since we do allocations one page at a time,
>that means we'd waste half our memory - and those wasted pages have
>malloc data structures in them, so it's real RAM that's wasted, not
>just address space.
>
>If cygwin's valloc were known not to do that, we could add logic to
>xvalloc.c so it would prefer valloc when compiled for cygwin.

Hmm.  Ok.  I can see why valloc would potentially waste a page of memory.
Cygwin would probably do the same thing since it uses Doug Lea's malloc
implementation which stores the malloc information "in band".

The problem I see with using VirtualAlloc is choosing a region of memory
that will not obstruct attempts to grow the heap.  I guess you have
the same problem with mmap, though, so maybe this isn't a real issue.

So, you're right, VirtualAlloc is probably a good way to do this.

Thanks for listening while I talk out loud and come to the same conclusions
that you have.  :-)

cgf