/* SVID2/XPG mallopt options */
#ifndef M_MXFAST
# define M_MXFAST 1 /* maximum request size for "fastbins" */
#endif
#ifndef M_NLBLKS
# define M_NLBLKS 2 /* UNUSED in this malloc */
#endif
#ifndef M_GRAIN
# define M_GRAIN 3 /* UNUSED in this malloc */
#endif
#ifndef M_KEEP
# define M_KEEP 4 /* UNUSED in this malloc */
#endif
/* mallopt options that actually do something */
#define M_TRIM_THRESHOLD -1
#define M_TOP_PAD -2
#define M_MMAP_THRESHOLD -3
#define M_MMAP_MAX -4
#define M_CHECK_ACTION -5
#define M_PERTURB -6
#define M_ARENA_TEST -7
#define M_ARENA_MAX -8
各項規則對應如下:
M_ARENA_MAX
This is the maximum number of arenas that can be created. The
value of M_ARENA_TEST is not used when M_ARENA_MAX is defined.
An arena represents a pool of memory that can be used by
(and similar) calls to service allocation requests.
Arenas are thread safe and therefore may have multiple
concurrent memory requests. The trade-off is between the
number of threads and the number of arenas. The more arenas
you have, the lower the per-thread contention, but the higher
the memory usage. This parameter has been available since
glibc 2.10 via --enable-experimental-malloc, and since glibc
2.15 by default. In some versions of the allocator there was
no limit on the number of created arenas (e.g., CentOS 5, RHEL
5).
When employing newer glibc versions, applications may in some
cases exhibit high contention when accessing arenas. In these
cases, it may be beneficial to increase M_ARENA_MAX to match
the number of threads. This is similar in behavior to
strategies taken by tcmalloc and jemalloc (e.g., per-thread
allocation pools).
M_ARENA_TEST
This is the limit, in number of arenas created, at which the
system configuration will be examined to evaluate a hard limit
on the number of created arenas. The computed limit is
implementation-defined and is usually a multiple of the number
of available CPUs. Once the limit is computed, the result is
final and constrains the total number of arenas. See
M_ARENA_MAX for the definition of an arena. This parameter
has been available since glibc 2.10 via
--enable-experimental-malloc, and since glibc 2.15 by default.
M_CHECK_ACTION
Setting this parameter controls how glibc responds when
various kinds of programming errors are detected (e.g.,
freeing the same pointer twice). The 3 least significant bits
(2, 1, and 0) of the value assigned to this parameter
determine the glibc behavior, as follows:
Bit 0 If this bit is set, then print a one-line message on
stderr that provides details about the error. The
message starts with the string "*** glibc
detected ***", followed by the program name, the name
of the memory-allocation function in which the error
was detected, a brief description of the error, and the
memory address where the error was detected.
Bit 1 If this bit is set, then, after printing any error
message specified by bit 0, the program is terminated
by calling abort(3). In glibc versions since 2.4, if
bit 0 is also set, then, between printing the error
message and aborting, the program also prints a stack
trace in the manner of backtrace(3), and prints the
process's memory mapping in the style of
/proc/[pid]/maps (see proc(5)).
Bit 2 (since glibc 2.4)
This bit has an effect only if bit 0 is also set. If
this bit is set, then the one-line message describing
the error is simplified to contain just the name of the
function where the error was detected and the brief
description of the error.
The remaining bits in value are ignored.
Combining the above details, the following numeric values are
meaningful for M_CHECK_ACTION:
0 Ignore error conditions; continue execution (with
undefined results).
1 Print a detailed error message and continue execution.
2 Abort the program.
3 Print detailed error message, stack trace, and memory
mappings, and abort the program.
5 Print a simple error message and continue execution.
7 Print simple error message, stack trace, and memory
mappings, and abort the program.
Since glibc 2.3.4, the default value for the M_CHECK_ACTION
parameter is 3. In glibc version 2.3.3 and earlier, the
default value is 1.
Using a nonzero M_CHECK_ACTION value can be useful because
otherwise a crash may happen much later, and the true cause of
the problem is then very hard to track down.
M_MMAP_MAX
This parameter specifies the maximum number of allocation
requests that may be simultaneously serviced using mmap(2).
This parameter exists because some systems have a limited
number of internal tables for use by mmap(2), and using more
than a few of them may degrade performance.
The default value is 65,536, a value which has no special
significance and which servers only as a safeguard. Setting
this parameter to 0 disables the use of mmap(2) for servicing
large allocation requests.
M_MMAP_THRESHOLD
For allocations greater than or equal to the limit specified
(in bytes) by M_MMAP_THRESHOLD that can't be satisfied from
the free list, the memory-allocation functions employ mmap(2)
instead of increasing the program break using sbrk(2).
Allocating memory using mmap(2) has the significant advantage
that the allocated memory blocks can always be independently
released back to the system. (By contrast, the heap can be
trimmed only if memory is freed at the top end.) On the other
hand, there are some disadvantages to the use of mmap(2):
deallocated space is not placed on the free list for reuse by
later allocations; memory may be wasted because mmap(2)
allocations must be page-aligned; and the kernel must perform
the expensive task of zeroing out memory allocated via
mmap(2). Balancing these factors leads to a default setting
of 128*1024 for the M_MMAP_THRESHOLD parameter.
The lower limit for this parameter is 0. The upper limit is
DEFAULT_MMAP_THRESHOLD_MAX: 512*1024 on 32-bit systems or
4*1024*1024*sizeof(long) on 64-bit systems.
Note: Nowadays, glibc uses a dynamic mmap threshold by
default. The initial value of the threshold is 128*1024, but
when blocks larger than the current threshold and less than or
equal to DEFAULT_MMAP_THRESHOLD_MAX are freed, the threshold
is adjusted upward to the size of the freed block. When
dynamic mmap thresholding is in effect, the threshold for
trimming the heap is also dynamically adjusted to be twice the
dynamic mmap threshold. Dynamic adjustment of the mmap
threshold is disabled if any of the M_TRIM_THRESHOLD,
M_TOP_PAD, M_MMAP_THRESHOLD, or M_MMAP_MAX parameters is set.
M_MXFAST (since glibc 2.3)
Set the upper limit for memory allocation requests that are
satisfied using "fastbins". (The measurement unit for this
parameter is bytes.) Fastbins are storage areas that hold
deallocated blocks of memory of the same size without merging
adjacent free blocks. Subsequent reallocation of blocks of
the same size can be handled very quickly by allocating from
the fastbin, although memory fragmentation and the overall
memory footprint of the program can increase. The default
value for this parameter is 64*sizeof(size_t)/4 (i.e., 64 on
32-bit architectures). The range for this parameter is 0 to
80*sizeof(size_t)/4. Setting M_MXFAST to 0 disables the use
of fastbins.
M_PERTURB (since glibc 2.4)
If this parameter is set to a nonzero value, then bytes of
allocated memory (other than allocations via calloc(3)) are
initialized to the complement of the value in the least
significant byte of value, and when allocated memory is
released using free(3), the freed bytes are set to the least
significant byte of value. This can be useful for detecting
errors where programs incorrectly rely on allocated memory
being initialized to zero, or reuse values in memory that has
already been freed.
M_TOP_PAD
This parameter defines the amount of padding to employ when
calling sbrk(2) to modify the program break. (The measurement
unit for this parameter is bytes.) This parameter has an
effect in the following circumstances:
* When the program break is increased, then M_TOP_PAD bytes
are added to the sbrk(2) request.
* When the heap is trimmed as a consequence of calling
free(3) (see the discussion of M_TRIM_THRESHOLD) this much
free space is preserved at the top of the heap.
In either case, the amount of padding is always rounded to a
system page boundary.
Modifying M_TOP_PAD is a trade-off between increasing the
number of system calls (when the parameter is set low) and
wasting unused memory at the top of the heap (when the
parameter is set high).
The default value for this parameter is 128*1024.
M_TRIM_THRESHOLD
When the amount of contiguous free memory at the top of the
heap grows sufficiently large, free(3) employs sbrk(2) to
release this memory back to the system. (This can be useful
in programs that continue to execute for a long period after
freeing a significant amount of memory.) The M_TRIM_THRESHOLD
parameter specifies the minimum size (in bytes) that this
block of memory must reach before sbrk(2) is used to trim the
heap.
The default value for this parameter is 128*1024. Setting
M_TRIM_THRESHOLD to -1 disables trimming completely.
Modifying M_TRIM_THRESHOLD is a trade-off between increasing
the number of system calls (when the parameter is set low) and
wasting unused memory at the top of the heap (when the
parameter is set high).