This is the mail archive of the cygwin-developers 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]
Other format: [Raw text]

Re: Windows heaps and Cygwin heap


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


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