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: New Cygwin family member


On 12/02/2013 6:00 AM, Corinna Vinschen wrote:
Hi guys,

On Feb 8 14:55, Corinna Vinschen wrote:
Another problem is the memory layout (the "fork" problem).  Fortunately
we have a 43 bit address space now.  Here's is our current model, still
open for discussion:

- Keep clear of memory from 0x0 up to 0x0:7fffffff, and from
   0x700:00000000 up to 0x7ff:ffffffff since these areas are used
   by the OS for ... everything.

- Cygwin thread stacks will be located between 0x0:80000000 and
   0x0:ffffffff.  With a default stack size of 1 Meg, we have room for
   2048 threads.

- The Cygwin executables will be loaded to 0x1:00400000.

- The Cygwin DLL will be loaded to 0x1:80040000.  That leaves 2 Gigs of
   space for the executable.  The space from 0x1:8000000 up to
   0x1:80040000 will be used for Cygwin's shared memory areas.
A slight change to the  memory model occured to me, which should drop
the potential DLL collisions even more:

- Other Cygwin distro DLLs are supposed to be rebased to the area
   between 0x2:00000000 up to 0x3:ffffffff.  This is an area of 8 Gigs
   for DLLs.  That should be enough for a while, I guess.
The memory slot from 0x2:00000000 up to 0x4:00000000 == 8 Gigs will be
used by rebase{all}...

...while ld's --auto-image-base will use the region from 0x4:00000000 up
to 0x6:00000000.

This means, rebased DLLs will never collide with auto-image-based DLLs,
and both types of DLLs have a full 8 Gigs space each, which should be
enough for the forseeable future.

- The heap will be located at 0x4:00000000, and it will be 512Megs by
   default.
The heap will then be located at 0x6:00000000, of course.

- Then ... a big void ...

- Eventually, mmap's will be allocated from 0x700:00000000 downwards.
This means the VM space left for heap and mmaps is a mere 7152 Gigabyte,
about 7 Terabytes.  I hope that's ok, even for our friends on the
Fortran frontier.

Comments?
If I count correctly:
- Total address space available is 8TB
- Windows no-man's land regions occupy 2GB and 1TB, respectively
- Cygwin thread stacks occupy 2GB
- Executable image gets 2GB
- distro and auto-image dlls together occupy 16GB (including some tens of MB for the cygwin dll and shared memory areas)
- heap/mmap area gets from 0x6: to 0x700:, which I compute as 7144GB


In other words, the proposed layout occupies only 20GB, or less than 0.3% of the address space. If somebody wants significantly more heap space, they'd have to brave the 1TB no-man's land and risk fork failures. Or, more likely, just wait for Intel and MS to bump the address space limit by a few powers of two (which should happen roughly when the "normal" amount of memory to have in a Windows box approaches 8TB). At that point, the heap/mmap area can easily take over the additional space.

What's not to like?
Ryan


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