Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com From: "Zack Weinberg" Date: Mon, 20 Nov 2000 18:29:47 -0800 To: Cygwin mailing list , GCC Bugs , GCC Patches 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 #include #include #include #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