OCS Fast Heap
The OCS Fast Heap is a user-defined malloc replacement for AIX (see: https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/generalprogramming/malloc_replace.html).
The OCS Fast Heap is designed to prioritize fast performance over more memory usage. The heap can be configured to match the exact heap profile (block size and count) required by an application for maximum performance, but also will automatically expand to meet demand (using sbrk()).
The OCS Fast Heap achieves its performance gains by using pools of fixed-size blocks. User requests are completed using the closest sized block. Blocks are never merged into larger blocks, so fragmentation is possible, but proper analysis (using hmp.ual) can avoid potential problems by determining program stated-state and peak needs.
[since: PowerAda AIX 5.8d1]
The OCS Fast Heap is delivered in an archive containing 32-bit and 64-bit version object files. The archive is located
$POWERADA/adarte/lib/ocs_fast_heap.a. You can check the version of the archive using the
strings ocs_fast_heap.a | grep ocs_fast_heap ocs_fast_heap.c 00.00.26 200901-17;20
The OCS Fast Heap can be activated by setting:
export LIBPATH=$LIBPATH:/path/to/ocs_fast_heap.a export MALLOCTYPE=user:ocs_fast_heap.a
The OCS Fast Heap will be used by all programs started the shell, and all programs started by those programs.
OCS Fast Heap options can be specified with:
export MALLOCOPTIONS=[<option>[,<option> ...]]
counts - keep usage counts. dontfailonce - don't fail once before using large-sized blocks; use larger blocks as soon as small block can't be created anymore. stats - produce stats in default file in CWD. stats:/path/to/file%d.txt - produce stats to named file. (%d=PID) pools:<pool-spec>[!<pool-spec] ...] - specify pool block sizes and pre-allocated counts where <pool-spec> is "<sizeInBytes>.<count>". All pools must be specified in increasing size. Pool block counts will increase as needed. A maximum of 40 pools can be specified.
The default pool size/count specification is:
Note that maximum pool size is limited by
INT64_MAX. This is half of the maximum value of
Debug options can be specified with:
export MALLOCDEBUG=<option>[,<option> ...]
debug - produce debug in default file in CWD debug:/path/to/file%d.txt - produce debug to named file. (%d = PID) abortdf - abort on double free abortua - abort on free of unknown address abortba - abort on free of bad (unaligned) address
The heap in core files can be debugged by referencing the
ocs_fast_heap.h include file. This file describes some structures used by the OCS Fast Heap and some tags used to mark the data in memory.
The OCS Fast Heap is thread-safe and can be used with multi-threaded programs.
The OCS Fast Heap will continue to return memory blocks as long as free blocks area available or space is available in the data segment. The OCS Fast Heap will first try to return a previously freed block in the appropriate pool. If none are available, the OCS Fast Heap will return a new memory block "carved" from the pre-allocated space available to each pool as specified by the pool defaults or the initial pool options. If no pre-allocated space is left, the OCS Fast Heap will allocate a block using the
sbrk() system call.
At this point, if the
sbrk() call fails, the OCS Fast Heap will return
NULL. This does not necessarily mean the heap space is exhausted. Smaller and larger blocks may still be available. Subsequent allocation calls after the first failure will attempt to use larger-sized blocks to fulfill the allocation request (to support error handling). Eventually, all larger blocks may be used and all subsequent allocation calls for a particular size block will return
dontfailonce will direct the OCS Fast Heap to not fail once before trying for larger blocks. Instead the OCS Fast Heap will try using larger blocks as soon as the appropriate sized blocks are not available.
The OCS Fast Heap does not implement
mallopt(). This call will always return 0. All options are specified using the
MALLOCOPTIONS environment variable.
The OCS Fast Heap does not implement
mallinfo(). This call will zero the
mallinfo struct parameter. All statistics are obtained using the
stats option. Calling
mallinfo will cause a new set of statistics to be written to the file (in addition to the normal periodic statistics).