HP-UX 11i December 2004 Release Notes

Process, Threads, Memory, and Kernel Parameters
Large Private Data Space
Chapter 10
226
Large Private Data Space
new at 11i
original release
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. This
change increases the amount of private data space available for a process.
New Options
Two new options have been added to the chatr command that allow the user to control
whether the 3rd quadrant (the 1GB of 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.
For example, System V shared memory and memory mapped files using a shared
mapping (MAP_SHARED).
The new options are as follows:
• +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 as private. Note that a q4p process implies that the 3rd quadrant
is private also. In other words, the kernel will not execute a process that only enables a
private 4th quadrant.
Because the system call gateway page has to remain at address 0xC0000000 for binary
compatibility reasons, the data segment cannot be extended past the beginning of the
4th quadrant. Therefore, the brk() and sbrk() system calls will only allow the data
segment to be expanded up to that address.
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. The system call
malloc() has been modified to do this automatically. No re-link will be necessary to take