Adaptive Address Space Whitepaper

the maxdsiz tunable appropriately, and ensure that enough swap is
available.
Similar constraints apply if other types of large objects are desired – e.g.
if a large stack was needed, then the maxssiz tunable and the
RLIMIT_STACK limit would have to be adjusted instead of the maxdsiz
tunable and RLIMIT_AS limit respectively.
The man page for setrlimit(2) is a good starting point for information on
resource limits. The man pages for the tunables maxssiz(5) and
maxdsiz(5) are good starting points for information on some of the
address space related tunables.
2. HP-UX on PA-RISC provides two types of layouts for binaries: q3private
and q4private. HP-UX PA-RISC binaries using these layouts were not
supported on IPF machines running HP-UX. On HP-UX 11i V2 onwards,
they will be supported, but will be treated as MPAS binaries on IPF
platforms.
3. HP-UX provides the “memory windows” functionality to 32-bit
applications that need more control over the usage of their shared
address space. Since 32-bit MPAS processes have the maximum
possible limit of 4GB of address space that can be used for shared
objects, MPAS processes should not have need to use the memory
windows functionality. In fact, combining MPAS processes and memory
windows is fraught with complications and is not recommended.
If such a combination is unavoidable, then the following points should
be borne in mind:
o MPAS processes can map objects not present in their memory
windows
o However, MPAS processes create objects in their own memory
windows. I.e. if Process A (MPAS) and process B (non-MPAS, say,
share magic) want to share an object. Then either:
i. Process B should create the object (e.g. shmget() with
IPC_CREAT)
ii. Or, Processes A and B should be in the same memory
window
iii. Or, Process A should do the shmget() with the
IPC_GLOBAL flag
More information on memory windows can be obtained from the link
provided in the section “for more information”.
10