home | help 
MALLOC(3)		     Library Functions Manual		       MALLOC(3)

NAME
     malloc, calloc, realloc, free, reallocf, malloc_usable_size -- general pur-
     pose memory allocation functions

LIBRARY
     Standard C Library (libc, -lc)

SYNOPSIS
     #include <stdlib.h>

     void *
     malloc(size_t size);

     void *
     calloc(size_t number, size_t size);

     void *
     realloc(void *ptr, size_t size);

     void *
     reallocf(void *ptr, size_t size);

     void
     free(void *ptr);

     const char * _malloc_options;

     void
     (*_malloc_message)(const char *p1, const char *p2, const char *p3,
	 const char *p4);

     #include <malloc_np.h>

     size_t
     malloc_usable_size(const void *ptr);

DESCRIPTION
     The  malloc()  function  allocates size bytes of uninitialized memory.  The
     allocated space is suitably aligned (after possible pointer  coercion)  for
     storage of any type of object.

     The  calloc()  function allocates space for number objects, each 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.

     The realloc() function changes the size of the previously allocated  memory
     referenced  by ptr to 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
     value of the newly allocated portion of the memory is undefined.  Upon suc-
     cess,  the memory referenced by ptr is freed and a pointer to the newly al-
     located memory is returned.  Note that realloc() and  reallocf()  may  move
     the  memory allocation, resulting in a different return value than ptr.  If
     ptr is NULL, the realloc() function behaves identically to malloc() for the
     specified size.

     The reallocf() function is identical to the realloc() function, except that
     it will free the passed pointer when the requested memory cannot  be  allo-
     cated.   This  is a FreeBSD specific API designed to ease the problems with
     traditional coding styles for realloc causing memory leaks in libraries.

     The free() function causes the allocated memory referenced  by  ptr  to  be
     made available for future allocations.  If ptr is NULL, no action occurs.

     The malloc_usable_size() function returns the usable size of the allocation
     pointed  to  by 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  alloca-
     tion  size  and the size reported by malloc_usable_size() should not be de-
     pended on, since such behavior is entirely implementation-dependent.

TUNING
     Once, when the first call is made to one of these	memory	allocation  rou-
     tines,  various  flags  will  be set or reset, which affect the workings of
     this allocator implementation.

     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 inter-
     preted, in that order, character by character as flags.

     Most  flags are single letters, where uppercase indicates that the behavior
     is set, or on, and lowercase means that the behavior is not set, or off.

     A	     All warnings (except for the warning about unknown flags being set)
	     become fatal.  The process will call abort(3) in these cases.

     H	     Use madvise(2) when pages within a chunk are no longer in use,  but
	     the  chunk as a whole cannot yet be deallocated.  This is primarily
	     of use when swapping is a real possibility, due to the  high  over-
	     head of the madvise() system call.

     J	     Each  byte  of new memory allocated by malloc(), realloc() or real-
	     locf() will be initialized to 0xa5.  All memory returned by free(),
	     realloc() or reallocf() will be initialized to 0x5a.  This  is  in-
	     tended for debugging and will impact performance negatively.

     K	     Increase/decrease the virtual memory chunk size by a factor of two.
	     The  default chunk size is 1 MB.  This option can be specified mul-
	     tiple times.

     N	     Increase/decrease the number of arenas by a factor of two.  The de-
	     fault number of arenas is four times the number of CPUs, or one  if
	     there  is	a  single  CPU.   This	option can be specified multiple
	     times.

     P	     Various statistics are printed at program	exit  via  an  atexit(3)
	     function.	 This  has  the potential to cause deadlock for a multi-
	     threaded process that exits while one or more threads are executing
	     in the memory allocation functions.  Therefore, this option  should
	     only  be  used with care; it is primarily intended as a performance
	     tuning aid during application development.

     Q	     Increase/decrease the size of the allocation quantum by a factor of
	     two.  The default quantum is the minimum allowed by  the  architec-
	     ture  (typically 8 or 16 bytes).  This option can be specified mul-
	     tiple times.

     S	     Increase/decrease the size of the maximum size class that is a mul-
	     tiple of the quantum by a factor of two.  Above this  size,  power-
	     of-two  spacing is used for size classes.	The default value is 512
	     bytes.  This option can be specified multiple times.

     U	     Generate "utrace" entries for ktrace(1), for all operations.   Con-
	     sult the source for details on this option.

     V	     Attempting  to  allocate  zero bytes will return a NULL pointer in-
	     stead of a valid pointer.	(The default behavior is to make a mini-
	     mal allocation and return a pointer to it.)  This	option	is  pro-
	     vided for System V compatibility.	This option is incompatible with
	     the "X" option.

     X	     Rather  than  return failure for any allocation function, display a
	     diagnostic message on stderr and cause the  program  to  drop  core
	     (using abort(3)).	This option should be set at compile time by in-
	     cluding the following in the source code:

		   _malloc_options = "X";

     Z	     Each  byte  of new memory allocated by malloc(), realloc() or real-
	     locf() will be initialized to 0.	Note  that  this  initialization
	     only  happens once for each byte, so realloc() and reallocf() calls
	     do not zero memory that was previously allocated.	This is intended
	     for debugging and will impact performance negatively.

     The "J" and "Z" options are intended for testing and debugging.  An  appli-
     cation which changes its behavior when these options are used is flawed.

IMPLEMENTATION NOTES
     Traditionally,  allocators have used sbrk(2) to obtain memory, but this im-
     plementation uses mmap(2), and only  uses	sbrk(2)  under	limited  circum-
     stances,  and only for 32-bit architectures.  As a result, the datasize re-
     source limit has little practical effect  for  typical  applications.   The
     vmemoryuse  resource limit, however, can be used to bound the total virtual
     memory used by a process, as described in limits(1).

     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 inde-
     pendently of each other, which means a small fixed increase in overall mem-
     ory  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 re-
     duced cache performance.  However, it may make sense to reduce  the  number
     of  arenas if an application does not make much use of the allocation func-
     tions.

     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 ob-
     jects 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 in a page map as
     runs of contiguous pages (unused, backing a set of small objects, or  back-
     ing  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 time.

     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  near-
     est 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  suf-
     fer from cache line sharing, round your allocation requests up to the near-
     est multiple of the cache line size.

DEBUGGING MALLOC PROBLEMS
     The first thing to do is to set the "A" option.  This option forces a core-
     dump  (if	possible)  at  the first sign of trouble, rather than the normal
     policy of trying to continue if at all possible.

     It is probably also a good idea to recompile the program with suitable  op-
     tions 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 sec-
     tion, 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 situa-
     tion,  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.

DIAGNOSTIC MESSAGES
     If  any  of the memory allocation/deallocation functions detect an error or
     warning  condition,  a  message  will  be	printed   to   file   descriptor
     STDERR_FILENO.  Errors will result in the process dumping core.  If the "A"
     option is set, all warnings are treated as errors.

     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 "<progname>: (malloc)".

RETURN VALUES
     The malloc() and calloc() functions return a pointer to the allocated  mem-
     ory if successful; otherwise a NULL pointer is returned and errno is set to
     ENOMEM.

     The realloc() and reallocf() functions return a pointer, possibly identical
     to  ptr, to the allocated memory if successful; otherwise a NULL pointer is
     returned, and errno is set to ENOMEM if the error was the result of an  al-
     location failure.	The realloc() function always leaves the original buffer
     intact  when  an  error  occurs,  whereas reallocf() deallocates it in this
     case.

     The free() function returns no value.

     The malloc_usable_size() function returns the usable size of the allocation
     pointed to by ptr.

ENVIRONMENT
     The following environment variables affect the execution of the  allocation
     functions:

     MALLOC_OPTIONS  If  the  environment  variable  MALLOC_OPTIONS  is set, the
		     characters it contains will be interpreted as flags to  the
		     allocation functions.

EXAMPLES
     To dump core whenever a problem occurs:

	   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";

SEE ALSO
     limits(1), madvise(2), mmap(2),  sbrk(2),	alloca(3),  atexit(3),	getpage-
     size(3), memory(3), posix_memalign(3)

STANDARDS
     The  malloc(),  calloc(), realloc() and free() functions conform to ISO/IEC
     9899:1990 ("ISO C90").

HISTORY
     The reallocf() function first appeared in FreeBSD 3.0.

     The malloc_usable_size() function first appeared in FreeBSD 7.0.

FreeBSD 7.0			  June 15, 2007 		       MALLOC(3)
home | help