Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Finding/changing max memory size available
Message-ID: <8169@auspex.auspex.com>
Date: 3 Jun 91 17:45:15 GMT
References: <24817@unix.SRI.COM> <1991May30.103731.28593@thunder.mcrcim.mcgill.edu> <13@tdatirv.UUCP>
Organization: Auspex Systems, Santa Clara
Lines: 13

>mmap() (or shmat()) may map a file or shared memory segment only a few K
>above the top user address, efectively placing a roadblock in the way
>of sbrk(), and thus limiting malloc().

It may, although hopefully those systems that, when asked to pick an
address for an "mmap()" or "shmat()", place it above the top user
address, rather than just below the stack limit (or above, on systems
where the stack grows upward in memory), will be dying out.

SunOS 4.x picks addresses just below the stack limit (the limit that
"getrlimit()" gets and "setrlimit()" sets); I suspect System V Release 4
does the same thing (yes, it has a stack limit, and "getrlimit()" and
"setrlimit()" as well).