HP-UX 11i September 2001 Release Notes

Process, Threads, Memory, and Kernel Parameters
Large Private Data Space (new at 11i original release)
Chapter 8
131
Large Private Data Space (new at 11i original release)
This change increases the amount of private data space available for a process. An
additional 1 to 2GB of private address space is now supported for 32-bit programs (if
enabled on a per process basis), at the expense of shared memory address space.
New Options
Two new options have been added to the chatr(1) command that allow the user to control
whether the 3rd quadrant (the 1GBof address space from 0x80000000-0xBFFFFFFF) and
the 4th quadrant (the 1GB of address space from 0xC0000000-0xFFFFFFFF) of a process
are part of the processes private address space or are shared with other running
processes. Previously, the 3rd and 4th quadrants were dedicated for shared object usage,
e.g. System V shared memory and memory mapped files using a shared mapping
(MAP_SHARED).
The new options are:
• +q3p <enable/disable>
• +q4p <enable/disable>
See the chatr (1) manpage for more details.
In order to use this new feature, the maxdsiz kernel configurable variable will need to be
increased appropriately. Also, the system will have to enable enough swap space to
support processes with large private address spaces.
Compatibility Issues
Processes that enable a private 3rd quadrant (q3p processes) will reduce the amount of
address space available for shared objects by 1GB. Also, q3p processes will not be able
to share objects that were created by another non-q3p process, even in the 4th
quadrant, unless those objects were created by the non-q3p process using the
IPC_GLOBAL flag (System V shared memory) or MAP_GLOBAL flag (mmap). If recompiling is
not an option, it will be necessary to make all processes that share objects with the q3p
process into q3p processes (chatr +q3p enable <a.out> ).
Processes that enable a private 4th quadrant (q4p processes), will have no address
space available for shared objects. This means that the process will not be able to use
System V shared memory, shared mapped files, etc. Shared libraries will still work,
although the kernel will map them private. Note that a q4p process implies that the
3rd quadrant is private also, i.e. the kernel will not execute a process that only enables a
private 4th quadrant.
The data segment cannot be extended past the beginning of the 4th quadrant, due to the
fact that the system call gateway page has to remain at address 0xC0000000 for binary
compatibility reasons. Therefore, the brk() and sbrk() system calls will only allow the
data segment to be expanded up to that address. In order to take advantage of
private address space in the 4th quadrant, memory will need to be allocated using the
mmap() system call with the MAP_PRIVATE option. malloc() has been modified to do
this automatically. No re-link will be necessary to take advantage of the new malloc()
for a program that uses a shared version of the C library. A program that was linked
with a non-shared library version of the C library, however, will need to be re-linked.