Space apportioned to a Process

Every process has 4 gigabytes of virtual address space available to it. The four-gigabyte space is subdivided into four one-gigabyte quadrants, each with a different usage. A process keeps track of its quadrants through space registers, which provide provide quadrant locations.

Table 1-2 Quadrants of virtual address space

Quadrant	Address Range and Purpose
1	0x00000000 - 0x3FFFFFFFContains process code (and EXEC_MAGIC data)
2	0x40000000 - 0x7FFFFFFFContains process data.
3	0x80000000 - 0xBFFFFFFFContains shared memory, shared memory mapped files, and shared library text.
4	0xC0000000 - 0xFFFFFFFFSame usage as quadrant 3. Bottom of quadrant 3 contains the gateway page.Address range 0xF0000000 to 0xFFFFFFFF is reserved for I/O address space.

The current 32-bit address space layout can be depicted by comparing how that virtual address space is used in kernel mode and user mode.

Figure 1-1 32-bit address space layout on PA1.x

The next figure shows that the various quadrants of a process might be distributed like a patchwork in the virtual address space. (the text might be in space ID 2 of quadrant 1, the shared libraries might be in space ID 1 of quadrant 3, and so on.) Each quadrant, however, handles a specific portion of the thread of execution.

Figure 1-2 Process structure layout, showing context and space use.

Handling maxdsiz with EXEC_MAGIC

Figure 1-3 Process address space in EXEC_MAGIC format

By default, a process's four GB address space is divided into four equal quadrants of one GB each. Each quadrant has a specific purpose (text, data, etc) and this accounts for the limitation on maxdsiz of ~960 MB.

An EXEC_MAGIC user executable (a.out) format allows data to start immediately after the code area in the first quadrant, instead of at the beginning of the second quadrant, and grow to the beginning of the user stack. Executables created with this format can handle more than 1 GB of data.

Data space starts in the first quadrant right after the process text and runs through the second quadrant. The data space uses up to approximately 1.9 gigabytes. For EXEC_MAGIC executables, the ~1.9GB limit represents the area from 0x00000000 to 0x7b03a000. The remainder is used for the stacks and uarea. For SHARED_MAGIC, data begins at 0x40000000. Everything else remains at the same location; the maximum stack size (maxssiz) remains 80MB.




	NOTE: To create an executable in `EXEC_MAGIC` format, link the executable with the `-N` option. (See `ld(1)` man page for details.)

EXEC_MAGIC executables can access more than .9GB of process private data because data is allowed to immediately follow text in quadrant one. For text and data to occupy the same quadrant, they must have the same space, yet process private data must have a unique space ID. Therefore, in the previous implementation of EXEC_MAGIC, text was actually viewed as a part of the data. Because HP-UX currently supports only one virtual translation per physical page (that is, one <space,offset> pair) , EXEC_MAGIC text cannot be shared between multiple processes. To overcome this limitation, the EXEC_MAGIC implementation allows read-only aliasing; multiple addresses can map the same physical page.

Because only one process actually owns a page translation, true copy-on-write is not currently implemented on HP-UX. When a second process attempts to read or write a shared page, the second process receives its own private copy of the page. With read-only aliasing, processes share a text page with different virtual addresses if they are only reading the page. A process will receive its own private copy of the page only when a write is performed.

Because EXEC_MAGIC text segments were considered part of the data segment, the text segment was writable. Because HP-UX guarantees swap space be available whenever a process requires, swap space was reserved for the entire text segment at exec() time. Because most users do not write to their text segment, the swap space reserved for the process is never used. To make more efficient use of swap space, a lazy swap reservation policy is implemented for EXEC_MAGIC text. Swap space is only reserved for pages being written to.

EXEC_MAGIC text is entirely loaded in at exec() time to protect against a.out modifications while the application is being run. EXEC_MAGIC guards against this problem by marking the EXEC_MAGIC executable VTEXT. This allows the text to be demand loaded, instead of being loaded entirely at exec() time.

Null reference semantics are supported on EXEC_MAGIC executables.




	NOTE: If you have an existing program that you have no source for or do not wish to recompile/link as `EXEC_MAGIC`, the process will retain a limit of ~960 MB for its data size.

Impact and Performance

More memory and swap space is available when running multiple copies of the same EXEC_MAGIC executable because unmodified text pages are now shared.
EXEC_MAGIC executables start up more quickly because text is now demand paged instead of being entirely loaded at exec() time.
EXEC_MAGIC executables execute more quickly because pages are copied on write instead of being copied on any access.
EXEC_MAGIC application failure is visible while running, if swap space is unavailable when the procress attempts to write to a page of text. This failure is not visible if self-modifying code is not used.
Demand paging and copy-on-write features improve performance of EXEC_MAGIC. Performance on SHARED_MAGIC executables remain unaffected.




	CAUTION: An `EXEC_MAGIC` application is subject to fail if insufficient swap space is available when the application attempts to write to a page of text. You must use self-modifying code to see this failure.

Space apportioned to a Process

Technical documentation

» Table of Contents

Handling maxdsiz with EXEC_MAGIC

Impact and Performance