malloc.3c (2010 09)

ManualsBrandsHP ManualsSoftwareHP-UX Manpages

malloc(3C) malloc(3C)

max_cache_misses

enables cached blocks to be exchanged among threads. A thread that heavily allo-

cates blocks of a certain size is soon bound to run out of blocks in its private cache. The exchange allows

the thread to borrow blocks from a global pool if available. This may be more efﬁcient than going back to

the arena.

max_cache_misses

is a hint to the caching algorithm indicating a particular number of

cache misses after which it will search the global pool for appropriate sized blocks. The algorithm also

releases unused cache blocks to the global pool. If

max_cache_misses

is 0 or not set, cache exchange

is turned off.

num_global_slots

is an indication of the size of the global cache pool. This parameter is valid only if

max_cache_misses

is turned on. The default value for num_global_slots

is 8.

The maximum number of blocks that will be cached for each thread is

bucket_size * buckets.

Here are examples of how to use

_M_CACHE_OPTS

$ export _M_CACHE_OPTS = 1024:32:20:4:8

This means that bucket_size is 1024, buckets

is 32, retirement_age is 20 minutes,

max_cache_misses

is 4, and num_global_slots

is 8.

$ export _M_CACHE_OPTS = 1024:32:20

This is a valid conﬁguration where the global pool is not activated.

_M_ARENA_OPTS and _M_CACHE_OPTS

have no effect on non-threaded applications, while

_M_SBA_OPTS has.

NOTE: Modifying these variables increases the chances of surfacing existing user memory defects such

as buffer overrun.

WARNINGS

malloc() functions use brk() and sbrk() (see brk(2)) to increase the address space of a process.

Therefore, an application program that uses brk() or sbrk() must not use them to decrease the

address space, because this confuses the malloc() functions.

free() and realloc() do not check their pointer argument for validity.

The following actions are considered bad programming practices and should not be done. The results are

unpredictable, probably undesirable and not supported. Examples of undesirable results are loss of data,

memory fault, bus error or inﬁnite loop.

• Attempting to

free() or realloc() a pointer not generated as the result of a call to

mal-

loc(), realloc(), calloc(),orvalloc().

• Reading or writing data outside the boundaries of an allocated block.

• Attempting to

realloc() an aligned block such as the result of valloc().

The following actions are strongly discouraged and may be unsupported in a future version of

mal-

loc():

• Attempting to

free() the same block twice.

• Depending on unmodiﬁed contents of a block after it has been freed.

• Attempting to

realloc() a block after it is freed.

Undocumented features of earlier memory allocators have not been duplicated. Applications which used

any of the above bad programming practices or discouraged practices are not guaranteed to continue

functioning at future releases.

Compatibility

The only external difference between the old malloc() allocator and the malloc() allocator is that

the old allocator would return a NULL pointer for a request of zero bytes. The malloc() allocator

returns a valid memory address. This is not a concern for most applications.

By default, SBA (Small Block Allocation) is turned on for Itanium-based systems and is turned off for

PA-RISC systems. This was due to performance concerns. Please refer to the EXTERNAL INFLU-

ENCES section of this manpage for details.