Heap storage is used to allocate storage that has a lifetime that is not related to the execution of the current routine. The storage is shared among all program units and all threads in an enclave. (Any thread can free heap storage.) It remains allocated until you explicitly free it or until the enclave terminates.

Heap storage can be allocated or freed several ways. When using C, storage is typically obtained using the malloc(), calloc(), and realloc() functions, and released using the free() function; for C++, the new and delete operators are used. For z/OS Language Environment, heap storage is made up of one or more heap segments that are comprised of an initial heap segment, and, as needed, one or more heap increments, which are allocated as additional storage is required. The initial heap may or may not be preallocated prior to the start of the application code, depending on the type of heap. See Figure 1 for an illustration of Language Environment® heap storage.

Each heap segment is subdivided into individual heap elements. Heap elements are obtained by a call to one of the heap allocation functions, and are allocated within the initial heap segment by the z/OS Language Environment storage management routines. When the initial heap segment becomes full, Language Environment gets another segment, or increment, from the operating system.

There are three basic types of heaps. The user heap is the heap storage that is used by the application program, and is obtained and freed by the various C/C++ mechanisms. The library heap is the heap storage that is used internally by Language Environment. In addition, the storage that is used by Language Environment I/O services are managed separately in the I/O heap.

Each heap is subdivided further, based on the requested location of the storage. There is a 64-bit heap for storage that is allocated above the 2-GB bar. For storage allocated below the 16-MB line, there is a 24-bit heap. And, for storage that is located above the 16-MB line but below the 2-GB bar, there is a 31-bit heap. Storage from the below-the-bar locations is useful for communicating with other programs or system services that are not capable of addressing above-the-bar storage. Language Environment provides two heap functions that the application can use to obtain storage from the below-the-bar heaps; __malloc24() is used to obtain storage from the 24-bit heap, and __malloc31() is used to obtain storage from the 31-bit heap. In both cases, the free() function is used to make the storage available again within the heap. See z/OS XL C/C++ Runtime Library Reference for more information about __malloc24() and __malloc31().

Language Environment provides runtime options to tune heap storage usage: HEAP64, LIBHEAP64, and IOHEAP64, for the user heap, library heap, and I/O heap, respectively. Within each of these runtime options, you can specify the size of the initial and increment segments for the 64-bit, 31-bit, and 24-bit sections of the heaps. You can also specify the disposition of an increment segment when it is no longer in use; KEEP indicates that the segment remains part of the heap, and FREE indicates that the segment storage should be returned to the operating system.

For the 64-bit section of the user heap, a third disposition FILL can be specified. When a storage request results in a new increment that is larger than incr64, there is often free space available within this increment. When this free space is used to satisfy other small requests, the disposition FREE will be less useful as this large increment might not become empty and therefore freed. To address this issue, the disposition FILL makes these large increments appear to have no free space, which allows them to be freed whenever the heap element which created them is freed. While using FILL allows these increments to be freed when no longer needed, they temporarily may be using more storage than otherwise required.

Note that the initial segment within each heap is never returned to the operating system. See the z/OS Language Environment Programming Reference for more details on these runtime options.

You can use the PAGEFRAMESIZE64 runtime option to request large page frames for heap storage. Large pages are a special-purpose feature to improve performance; therefore, using large pages is not recommended for all types of workloads. See z/OS MVS Programming: Assembler Services Guide for more information about large pages.

You can use the Language Environment STORAGE option to diagnose the use of uninitialized and freed storage.

You can use the HEAPCHK runtime option to run heap storage tests, and to help identify storage leaks. The HEAPZONES runtime option can be used to identify storage overlay damage.

See Using runtime options and z/OS Language Environment Programming Reference for more information about using Language Environment runtime options.

Figure 1 shows the Language Environment heap storage model.

Figure 1. Language Environment heap storage model