Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
From: "Zack Weinberg" <zackw AT stanford DOT edu>
Date: Mon, 20 Nov 2000 18:56:23 -0800
To: Cygwin mailing list <Cygwin AT cygwin DOT com>, GCC Bugs <gcc-bugs AT gcc DOT gnu DOT org>,
        GCC Patches <gcc-patches AT gcc DOT gnu DOT org>
Subject: Re: Reason for cygwin GCC 2.97 non-bootstrap found
Message-ID: <20001120185623.X17712@wolery.stanford.edu>
References: <200011202245 DOT eAKMjjN27680 AT plmlir3 DOT mail DOT eds DOT com> <20001120154222 DOT O17712 AT wolery DOT stanford DOT edu> <20001120201358 DOT H11780 AT redhat DOT com> <20001120182947 DOT U17712 AT wolery DOT stanford DOT edu> <20001120214041 DOT A31228 AT redhat DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001120214041.A31228@redhat.com>; from cgf@redhat.com on Mon, Nov 20, 2000 at 09:40:41PM -0500

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

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com