FreeBSD 7.0 manual page repository

FreeBSD is a free computer operating system based on BSD UNIX originally. Many IT companies, like DeployIS is using it to provide an up-to-date, stable operating system.

malloc, calloc, realloc, free, reallocf, malloc_usable_size - general

 

NAME

      malloc, calloc, realloc, free, reallocf, malloc_usable_size - general
      purpose 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 mem‐
      ory 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 unde‐
      fined.  Upon success, the memory referenced by 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 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
      allocated.  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 alloca‐
      tion 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 allocation size and the size reported by malloc_usable_size()
      should not be depended on, since such behavior is entirely implementa‐
      tion-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
      interpreted, in that order, character by character as flags.
 
      Most flags are single letters, where uppercase indicates that the behav‐
      ior 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 pri‐
              marily of use when swapping is a real possibility, due to the
              high overhead of the madvise() system call.
 
      J       Each byte of new memory allocated by malloc(), realloc() or
              reallocf() will be initialized to 0xa5.  All memory returned by
              free(), realloc() or reallocf() will be initialized to 0x5a.
              This is intended for debugging and will impact performance nega‐
              tively.
 
      K       Increase/decrease the virtual memory chunk size by a factor of
              two.  The default chunk size is 1 MB.  This option can be speci‐
              fied multiple times.
 
      N       Increase/decrease the number of arenas by a factor of two.  The
              default 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 execut‐
              ing in the memory allocation functions.  Therefore, this option
              should only be used with care; it is primarily intended as a per‐
              formance 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 archi‐
              tecture (typically 8 or 16 bytes).  This option can be specified
              multiple times.
 
      S       Increase/decrease the size of the maximum size class that is a
              multiple 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.
              Consult the source for details on this option.
 
      V       Attempting to allocate zero bytes will return a NULL pointer
              instead of a valid pointer.  (The default behavior is to make a
              minimal allocation and return a pointer to it.)  This option is
              provided 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
              including the following in the source code:
 
                    _malloc_options = "X";
 
      Z       Each byte of new memory allocated by malloc(), realloc() or
              reallocf() will be initialized to 0.  Note that this initializa‐
              tion 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
      application which changes its behavior when these options are used is
      flawed.
      Traditionally, allocators have used sbrk(2) to obtain memory, but this
      implementation uses mmap(2), and only uses sbrk(2) under limited circum‐
      stances, and only for 32-bit architectures.  As a result, the datasize
      resource limit has little practical effect for typical applications.  The
      vmemoryuse resource limit, however, can be used to bound the total vir‐
      tual 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 com‐
      pletely 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 sub‐
      stantially more arenas than the default is not likely to improve perfor‐
      mance, 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 multi‐
      ple 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 infre‐
      quently 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
      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 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 quan‐
      tum-multiple size class (see the “S” option) are rounded up to the near‐
      est 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.
      The first thing to do is to set the “A” option.  This option forces a
      coredump (if possible) at the first sign of trouble, rather than the nor‐
      mal policy of trying to continue if at all possible.
 
      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 pro‐
      gram 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 prob‐
      lems by trading performance for extra sanity checks and detailed diagnos‐
      tics.
      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 func‐
      tion 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)”.
      The malloc() and calloc() functions return a pointer to the allocated
      memory if successful; otherwise a NULL pointer is returned and errno is
      set to ENOMEM.
 
      The realloc() and reallocf() functions return a pointer, possibly identi‐
      cal 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 allocation failure.  The realloc() function always leaves
      the original buffer intact when an error occurs, whereas reallocf() deal‐
      locates it in this case.
 
      The free() function returns no value.
 
      The malloc_usable_size() function returns the usable size of the alloca‐
      tion pointed to by ptr.
 

ENVIRONMENT

      The following environment variables affect the execution of the alloca‐
      tion 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";
      limits(1), madvise(2), mmap(2), sbrk(2), alloca(3), atexit(3),
      getpagesize(3), memory(3), posix_memalign(3)
 

STANDARDS

      The malloc(), calloc(), realloc() and free() functions conform to ISO/IEC
      9899:1990 (“ISO C89”).
 

HISTORY

      The reallocf() function first appeared in FreeBSD 3.0.
 
      The malloc_usable_size() function first appeared in FreeBSD 7.0.
 

Sections

Based on BSD UNIX
FreeBSD is an advanced operating system for x86 compatible (including Pentium and Athlon), amd64 compatible (including Opteron, Athlon64, and EM64T), UltraSPARC, IA-64, PC-98 and ARM architectures. It is derived from BSD, the version of UNIX developed at the University of California, Berkeley. It is developed and maintained by a large team of individuals. Additional platforms are in various stages of development.