This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Reason for cygwin GCC 2.97 non-bootstrap found
On Mon, Nov 20, 2000 at 09:40:41PM -0500, Christopher Faylor wrote:
> On Mon, Nov 20, 2000 at 06:29:47PM -0800, Zack Weinberg wrote:
> >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.
Considering the point of munmap is to give the page back to the
operating system, I doubt VirtualProtect would help.
...
> 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.
ggc-page.c (and xvalloc.c) punt this to the mmap implementation. On
Unix systems, if you don't tell the kernel where to put the memory
you're allocating, it puts it somewhere it's unlikely to collide with
the heap being grown by brk(2). [On Linux, the break starts around
0x08000000, and mmaped blocks live above 0x40000000.] I don't know
what VirtualAlloc does if you give it a null first argument; I do see
that heap.cc specifically asks for memory adjacent to where the
library's fake break is...
Is it necessary to do VirtualAlloc(... MEM_RESERVE ...) before
VirtualAlloc(... MEM_COMMIT ...) ?
zw