This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Reason for cygwin GCC 2.97 non-bootstrap found


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.

>That change was a marginal performance hack and I don't think it'd do
>any harm to scrap it.  However, I am currently testing a patch which
>moves the memory allocation mess into libiberty.  (It's a modified
>version of the patch by Alexandre Oliva and Laurnyas Bivenis - less
>complex, hopefully just as effective.)  I'd be curious to know how it
>works on cygwin.  Patch is appended.
>
>It'd probably be a good idea to add additional autoconf and #ifdef
>logic so that xvalloc.c uses VirtualAlloc() instead of Cygwin's mmap
>on Win32 hosts.

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?

cgf

>WARNING: This patch temporarily removes the ability to allocate
>objects larger than one page with ggc_alloc.  I haven't yet had any
>problems, but a ridiculously huge switch statement might trip over the
>limitation.
>
>NOTE: There are a bunch of technically unrelated cleanups to the
>libiberty configure.in in here.
>[snip]

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]