Open System Services Porting Guide (G06.29+, H06.06+, J06.03+)

storage class specifier.) Both global and static aggregates have storage class static, which means
that they retain their values throughout the execution of the entire program.
The main stack of a native process can grow in size dynamically, up to a default or specified limit.
By default that limit is 1 megabyte (MB) on TNS/R systems or 2 MB on TNS/E systems; on both
platforms you can specify a limit of up to 32 MB. You can also specify a maximum heap size value
with the nld, ld, or eld utility or with the process-creation procedures.
Memory Allocation and Deallocation
For local (automatic) variables, which are allocated from the stack, storage is created when the
block containing the variable declaration is entered. The storage is released when the block is
exited. When space is created for a local variable, the name and created space are linked; they
cannot change while the variable exists. The stack area is reserved for the run-time stack.
For dynamic variables, which are allocated from the heap, storage is created by using the
memory-management function calls: calloc(), malloc(), realloc(), or the C++ operator
new. The newly created space is allocated, and the value returned by the memory-management
function points to the allocated memory. Thus, allocation and naming are tied together.
The essential difference between stack-based and heap-based storage allocation is that a local
variable is allocated when the block (or function) containing the variable is entered and freed
when the block or function is exited. A dynamic variable’s lifetime is determined explicitly by the
programmer. (For example, by invoking the free() function or free operator.)
When memory is allocated from the heap, you must keep track of values to determine when they
are no longer useful, and explicitly free their space by calling free(). If memory is not managed
properly, the following problems can occur:
• Memory allocated from the heap might never be released until the process terminates.
• An attempt is made to use memory that has already been freed.
If your program uses older memory-allocation calls that use nonportable routines such as brk(),
sbrk(), and alloca(), update your code to use standard memory allocation functions:
malloc() and free(). See Table 8 (page 111) for recommendations on substitutions for functions
not provided in the OSS API.
Beginning with the H06.24 and J06.13 RVUs, additional OSS functions and Guardian procedures
have been added to manage memory. For information about these new memory functions and
procedures, see the 64-Bit Support in OSS and Guardian chapter in the Open System Services
Programmer's Guide.
Swap Space Management
The Kernel-Managed Swap Facility (KMSF) manages swap space (backing store) for virtual memory.
The space guarantee attribute (pe_space_guarantee) of a process can be used by KMSF to
reserve space in system swap files. If the requested space is not available at process creation, an
error is returned, and the process is not started.
KMSF is used unconditionally for many segments and by default in other segments as an alternative
for backing to explicit files. For more information on KMSF, see the Kernel-Managed Swap Facility
(KMSF) Manual.
Considering Design Trade-Offs
Because of the way in which some of the UNIX features are implemented in the OSS environment,
there may be some performance implications in using these features. The NonStop operating system
uses a loosely coupled multiprocessing architecture; therefore, different design alternatives might
need to be considered in porting UNIX programs to the OSS environment.
When you must modify code to move it to another environment, you weigh standards and portability
against extensions and performance. If your main priority is portability, you should conform to the
Considering Design Trade-Offs 95