Open System Services Porting Guide (G06.24+, H06.03+)

OSS Porting Considerations
Open System Services Porting Guide—520573-006
6-11
Memory Allocation and Deallocation
Also, see Section 8, Migrating Guardian Applications to the OSS Environment, for
memory-model incompatibilities that require conversion when porting Guardian
applications that use a memory-model not supported by OSS programs.
The large-memory model stores the heap and the global and static aggregates in a
single extended memory segment. (Static aggregate refers to an aggregate that is
declared with the static 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.
User processes initially can have a stack size of 1 megabyte (MB) on TNS/R systems
or 2 MB on TNS/E systems, and the stack size on both platforms can be specified to
be up to 32 MB. You can specify the maximum value for the size of the stack. The
stack can grow in size dynamically. You can also specify a maximum heap size value
with the nld, ld, or eld utility or with the process creation procedures.
Selectable and flat segments are supported in the native and TNS environments. Flat
segments are supported in the native environments for compatibility with TNS
processes. All flat segments are available at the same time. Flat segments in TNS
processes are allocated to a 32-MB boundary, and a maximum of 13 segments may be
allocated per process. For native processes, flat segments are allocated to a 128-
kilobyte boundary, with no practical limit to the number of segments for each process.
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 7-1 on page 7-6 for
recommendations on substitutions for functions not provided in the OSS API.
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(), or realloc(). 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 and is independent of the flow of control.
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() or
exit(). If memory is not managed properly, the following problems can occur:
•
Memory allocated from the heap might never be released.