Windows heaps and Cygwin heap

[Ryan Johnson]

On 17/05/2011 11:32 AM, Corinna Vinschen wrote:
> On May 17 07:12, Ryan Johnson wrote:
>> On 17/05/2011 4:19 AM, Corinna Vinschen wrote:
>>> On May 13 06:32, Ryan Johnson wrote:
>>>> In any case, I also have never seen problems above 0x20000000.
>>> I'm looking into the heap and stack addresses for a good amount of time
>>> now.  Since we're talking about Cygwin applications only, which don't
>>> use HeapCreate, we only have to care for heaps created by Win32 DLLs.
>>>
>>> What I'm observing is that even big apps like vim, emacs, octave don't
>>> use addresses beyond 0x03000000.  Setting the heap to an address of
>>> 0x20000000 appears to be a rather big waste of memory.
>>>
>>> So I'm planning to drop the bar to 0x08000000, which gives the heap
>>> a potential extra memory of 384 Megs. and still leaves a confortable
>>> cushion of 80 Megs for the OS.
>>>
>>> Does anybody see a good reason not to do that, like, say, different
>>> observations of the memory address usage by OS DLLs and stuff?
>> On my machine, running 'emacs-X11 -nw', quite a bit of stuff appears
>> at 0x01????? (showing only allocation bases below for brevity):
>>> [...]
>> Another bunch appears in the 0x19??????-0x1C?????? range (again,
>> allocation bases only):
>>> 19A80000-19C7B000 ---p 00000000 0000:0000 0
>>> [...]
>> While cygxml2-2.dll presumably needs rebased and can be made to
>> move, I think the rest is there to stay.
> That's kind of annoying.  I wouldn't have believed that the OS DLLs
> would take so much memory.  I'll stick to 0x20000000 for now.
annoying++

I just assume that Windows always does its best to prevent cygwin's 
fork() from succeeding consistently. Even if it's not intentional, 
Murphy's Law has enough raw materials to work with that it may as well be.

It's really too bad the crss stuff isn't documented/reliable... so 
frustrating to know native fork() can be done and yet have no way to use it.

Ryan