Mail Archives: cygwin/2000/11/20/21:30:36
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
- Raw text -