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:29:47 -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: <20001120182947.U17712@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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001120201358.H11780@redhat.com>; from cgf@redhat.com on Mon, Nov 20, 2000 at 08:13:58PM -0500

On Mon, Nov 20, 2000 at 08:13:58PM -0500, Christopher Faylor wrote:
> On Mon, Nov 20, 2000 at 03:42:23PM -0800, Zack Weinberg wrote:
> >On Mon, Nov 20, 2000 at 05:45:26PM -0500, Kelley Cook wrote:
> >> After much binary searching this weekend, I discovered the reason why
> >> Cygwin hasn't been able to bootstrap since late August.
> >...
> >>         * ggc-page.c (alloc_page): If HAVE_MMAP_ANYWHERE and we're
> >>         asked for one page, allocate GGC_QUIRE_SIZE of them and put
> >>         the extras on the free list.
> >
> >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.
I don't see any way to do what ggc-page.c wants with this interface.
It sounds like it could be done with VirtualAlloc/VirtualFree, though,
which would also have the advantage of not putting the GC heap into
the "global memory region" in Win95.

Here's a simple test program.

#include <sys/types.h>
#include <sys/mman.h>
#include <unistd.h>
#include <string.h>

#define PAGEPROT PROT_READ|PROT_WRITE
#define MAPFLAGS MAP_PRIVATE|MAP_ANONYMOUS

int main(void)
{
  size_t pagesize = getpagesize();
  char *base;

  base = mmap(0, 16*pagesize, PAGEPROT, MAPFLAGS, -1, 0);
  memset(base, 0xAB, 16*pagesize);

  munmap(base + 4*pagesize, pagesize);

  memset(base, 0xCD, 4*pagesize);
  memset(base + 5*pagesize, 0xCD, 10*pagesize);

  return 0;
}  

> 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.

zw

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