Next | Prev | Up | Top | Contents | Index
Delayed and Immediate Space Definition
IRIX supports two radically different ways of defining segments of address space.
The conventional behavior of UNIX systems, and the default behavior of current releases of IRIX, is that space created using brk() or malloc() is immediately defined. Page table entries are created to define the addresses, and swap space is allocated as a backing store. Three results follow from the conventional method:
- A program can detect immediately when swap space is exhausted. A call to malloc() returns NULL when memory cannot be allocated. A program can find the limits of swap space by making repeated calls to malloc().
- A large memory allocation by one program can fill swap, causing other programs to see out-of-memory errors--whether the program ever uses its allocated memory or not.
- A fork() or exec() call fails unless there is free space in swap equal to the data and stack sizes of the new process.
By default in IRIX 5.2, and optionally in later releases, IRIX uses a different method sometimes called "virtual swap." In this method, the definition of new segments is delayed until the space is actually used. Functions like brk() and malloc() merely test the new size of the data segment against the resource limits. They do not actually define the new addresses, and they do not cause swap disk space to be allocated. Addresses are reserved with brk() or malloc(), but they are only defined and allocated in swap when your program references them.
When IRIX uses delayed definition ("virtual swap"), it has the following effects:
You can test whether the system uses virtual swap with the chkconfig command (as described in the chkconfig(1) reference page):
# chkconfig vswap; echo $status
0
As you write a new program, assume that virtual swap may be used. Do not allocate memory merely to find out if you can. Allocate no more memory than your program needs, and use the memory immediately after allocating it.
If you are porting a program written for a conventional UNIX system, you might discover that it tests the limits of allocatable memory by calling malloc() until malloc() returns a NULL, and then does not use the memory. In this case you have several choices:
- Recode this part of the program to derive the maximum memory size in some more reasonable and portable way, for instance from an environment variable or the size of an input file.
- Using setrlimit(), set a lower maximum for rlimit_data_max, so that malloc() returns NULL at a reasonable allocation size (see the getrlimit(2) reference page).
- Restore the conventional UNIX behavior for the whole system. Use chkconfig to turn off the variable vswap, and reboot (see the chkconfig(1) reference page).
Note: The function calloc() touches all allocated pages in the course of filling them with zeros. Hence memory allocated by calloc() is defined as soon as it is allocated. However, you should not rely on this behavior. It is possible to implement calloc() in such a way that it, like malloc(), does not define allocated pages until they are used. This might be done in a future version of IRIX.
Next | Prev | Up | Top | Contents | Index