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
Date: Mon, 20 Nov 2000 21:40:41 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
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: <20001120214041.A31228@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-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>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <20001120182947.U17712@wolery.stanford.edu>; from zackw@stanford.edu on Mon, Nov 20, 2000 at 06:29:47PM -0800

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

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