malloc , calloc , realloc , free , reallocf , malloc_usable_size - general purpose memory allocation functions
function allocates space for Fa number objects, each Fa size bytes in length. The result is identical to calling malloc ();
with an argument of ``number * size'' with the exception that the allocated memory is explicitly initialized to zero bytes.
function changes the size of the previously allocated memory referenced by Fa ptr to Fa size bytes. The contents of the memory are unchanged up to the lesser of the new and old sizes. If the new size is larger, the contents of the newly allocated portion of the memory are undefined. Upon success, the memory referenced by Fa ptr is freed and a pointer to the newly allocated memory is returned. Note that realloc ();
and reallocf ();
may move the memory allocation, resulting in a different return value than Fa ptr . If Fa ptr is NULL the realloc ();
function behaves identically to malloc ();
for the specified size.
function is identical to the realloc ();
function, except that it will free the passed pointer when the requested memory cannot be allocated. This is a Fx specific API designed to ease the problems with traditional coding styles for realloc causing memory leaks in libraries.
function causes the allocated memory referenced by Fa ptr to be made available for future allocations. If Fa ptr is NULL no action occurs.
function returns the usable size of the allocation pointed to by Fa ptr . The return value may be larger than the size that was requested during allocation. The malloc_usable_size ();
function is not a mechanism for in-place realloc (;);
rather it is provided solely as a tool for introspection purposes. Any discrepancy between the requested allocation size and the size reported by malloc_usable_size ();
should not be depended on, since such behavior is entirely implementation-dependent.
The ``name'' of the file referenced by the symbolic link named /etc/malloc.conf the value of the environment variable MALLOC_OPTIONS and the string pointed to by the global variable _malloc_options will be interpreted, in that order, from left to right as flags.
Each flag is a single letter, optionally prefixed by a non-negative base 10 integer repetition count. For example, ``3N'' is equivalent to ``NNN'' Some flags control parameter magnitudes, where uppercase increases the magnitude, and lowercase decreases the magnitude. Other flags control boolean parameters, where uppercase indicates that a behavior is set, or on, and lowercase means that a behavior is not set, or off.
_malloc_options = "X";
The ``J'' and ``Z'' options are intended for testing and debugging. An application which changes its behavior when these options are used is flawed.
This allocator uses multiple arenas in order to reduce lock contention for threaded programs on multi-processor systems. This works well with regard to threading scalability, but incurs some costs. There is a small fixed per-arena overhead, and additionally, arenas manage memory completely independently of each other, which means a small fixed increase in overall memory fragmentation. These overheads are not generally an issue, given the number of arenas normally used. Note that using substantially more arenas than the default is not likely to improve performance, mainly due to reduced cache performance. However, it may make sense to reduce the number of arenas if an application does not make much use of the allocation functions.
Memory is conceptually broken into equal-sized chunks, where the chunk size is a power of two that is greater than the page size. Chunks are always aligned to multiples of the chunk size. This alignment makes it possible to find metadata for user objects very quickly.
User objects are broken into three categories according to size: small, large, and huge. Small objects are no larger than one half of a page. Large objects are smaller than the chunk size. Huge objects are a multiple of the chunk size. Small and large objects are managed by arenas; huge objects are managed separately in a single data structure that is shared by all threads. Huge objects are used by applications infrequently enough that this single data structure is not a scalability issue.
Each chunk that is managed by an arena tracks its contents as runs of contiguous pages (unused, backing a set of small objects, or backing one large object). The combination of chunk alignment and chunk page maps makes it possible to determine all metadata regarding small and large allocations in constant and logarithmic time, respectively.
Small objects are managed in groups by page runs. Each run maintains a bitmap that tracks which regions are in use. Allocation requests that are no more than half the quantum (see the ``Q'' option) are rounded up to the nearest power of two (typically 2, 4, or 8). Allocation requests that are more than half the quantum, but no more than the maximum quantum-multiple size class (see the ``S'' option) are rounded up to the nearest multiple of the quantum. Allocation requests that are larger than the maximum quantum-multiple size class, but no larger than one half of a page, are rounded up to the nearest power of two. Allocation requests that are larger than half of a page, but small enough to fit in an arena-managed chunk (see the ``K'' option), are rounded up to the nearest run size. Allocation requests that are too large to fit in an arena-managed chunk are rounded up to the nearest multiple of the chunk size.
Allocations are packed tightly together, which can be an issue for multi-threaded applications. If you need to assure that allocations do not suffer from cache line sharing, round your allocation requests up to the nearest multiple of the cache line size.
It is probably also a good idea to recompile the program with suitable options and symbols for debugger support.
If the program starts to give unusual results, coredump or generally behave differently without emitting any of the messages mentioned in the next section, it is likely because it depends on the storage being filled with zero bytes. Try running it with the ``Z'' option set; if that improves the situation, this diagnosis has been confirmed. If the program still misbehaves, the likely problem is accessing memory outside the allocated area.
Alternatively, if the symptoms are not easy to reproduce, setting the ``J'' option may help provoke the problem.
In truly difficult cases, the ``U'' option, if supported by the kernel, can provide a detailed trace of all calls made to these functions.
Unfortunately this implementation does not provide much detail about the problems it detects; the performance impact for storing such information would be prohibitive. There are a number of allocator implementations available on the Internet which focus on detecting and pinpointing problems by trading performance for extra sanity checks and detailed diagnostics.
The _malloc_message variable allows the programmer to override the function which emits the text strings forming the errors and warnings if for some reason the stderr file descriptor is not suitable for this. Please note that doing anything which tries to allocate memory in this function is likely to result in a crash or deadlock.
All messages are prefixed by ``Ao progname Ac : (malloc) ''
and reallocf ();
functions return a pointer, possibly identical to Fa ptr , to the allocated memory if successful; otherwise a NULL pointer is returned, and errno is set to Er ENOMEM if the error was the result of an allocation failure. The realloc ();
function always leaves the original buffer intact when an error occurs, whereas reallocf ();
deallocates it in this case.
function returns no value.
function returns the usable size of the allocation pointed to by Fa ptr .
ln -s 'A' /etc/malloc.conf
To specify in the source that a program does no return value checking on calls to these functions:
_malloc_options = "X";
function first appeared in Fx 7.0 .
Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру