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