Process map and fork problems
Wed Apr 20 14:20:00 GMT 2016
On Apr 20 11:24, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > I think all the affected machines have 4GB memory installed, but the
> > > option may not have been default when they were installed.
> > They never are default. Default is 2 Gigs application VM, 2 Gigs
> > kernel̇ memory space. Specifying /3Gb means 3 Gigs application VM
> > vs. 1 Gig kernel̇ memory space. That's not always a good thing
> > since it could lead to kernel memory pool exhaustion.
> I meant "not default in the base install image provided by corporate IT".
> I'll have to ask if they have some special procedure to switch it on.
> > > With /3GB you mean 4GT (aka PAE), right? And 32bit is without PAE?
> > No, PAE works differently, using different calls. I'm talking abut
> > the normal 32 bit address space of a 32 bit CPU.
> Hmm. Microsoft's 4GT documentation makes you believe that /3GB and PAE is
> always coupled, though. But then even non-/3GB might laready use some PAE
> facilities anyway. But I guess it's not important.
> > It can only know its own heap. But keep in mind that the heap can
> > be differently sized in different applications. The heap only *starts*
> > as a 384Meg heap, it could easly grow in big apps (gcc, emacs, ...)
> > when calling sbrk.
> So it can grow only so much until it runs into the first loaded DLL above?
> Or does it fragment into yet unused areas then?
It can't fragment, it can only grow. The Unix heap management doesn't
have the notion of multiple application heaps. There's only the sbrk
call to raise or shrink the size of the heap.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Cygwin