Main Page | Modules | Data Structures | Directories | File List | Data Fields | Globals | Related Pages

malloc.h

Go to the documentation of this file.
00001 /*
00002   Default header file for malloc-2.7.2, written by Doug Lea
00003   and released to the public domain.  Use, modify, and redistribute
00004   this code without permission or acknowledgement in any way you wish.
00005   Send questions, comments, complaints, performance data, etc to
00006   dl@cs.oswego.edu.
00007  
00008   last update: Sun Feb 25 18:38:11 2001  Doug Lea  (dl at gee)
00009 
00010   This header is for ANSI C/C++ only.  You can set either of
00011   the following #defines before including:
00012 
00013   * If USE_DL_PREFIX is defined, it is assumed that malloc.c 
00014     was also compiled with this option, so all routines
00015     have names starting with "dl".
00016 
00017   * If HAVE_USR_INCLUDE_MALLOC_H is defined, it is assumed that this
00018     file will be #included AFTER <malloc.h>. This is needed only if
00019     your system defines a struct mallinfo that is incompatible with the
00020     standard one declared here.  Otherwise, you can include this file
00021     INSTEAD of your system system <malloc.h>.  At least on ANSI, all
00022     declarations should be compatible with system versions
00023 */
00024 
00025 #ifndef MALLOC_270_H
00026 #define MALLOC_270_H
00027 
00028 #ifdef __cplusplus
00029 extern "C"
00030 {
00031 #endif
00032 
00033 #include <stddef.h>             /* for size_t */
00034 
00035 /*
00036   malloc(size_t n)
00037   Returns a pointer to a newly allocated chunk of at least n bytes, or
00038   null if no space is available. Additionally, on failure, errno is
00039   set to ENOMEM on ANSI C systems.
00040 
00041   If n is zero, malloc returns a minimum-sized chunk. The minimum size
00042   is 16 bytes on most 32bit systems, and either 24 or 32 bytes on
00043   64bit systems, depending on internal size and alignment restrictions.
00044 
00045   On most systems, size_t is an unsigned type.  Calls with values of n
00046   that appear "negative" when signed are interpreted as requests for
00047   huge amounts of space, which will most often fail.
00048 
00049   The maximum allowed value of n differs across systems, but is in all
00050   cases less (typically by 8K) than the maximum representable value of
00051   a size_t. Requests greater than this value result in failure.
00052 */
00053 
00054 #ifndef USE_DL_PREFIX
00055    void *malloc(size_t);
00056 #else
00057    void *dlmalloc(size_t);
00058 #endif
00059 
00060 /*
00061   free(void* p)
00062   Releases the chunk of memory pointed to by p, that had been previously
00063   allocated using malloc or a related routine such as realloc.
00064   It has no effect if p is null. It can have arbitrary (and bad!)
00065   effects if p has already been freed or was not obtained via malloc.
00066 
00067   Unless disabled using mallopt, freeing very large spaces will,
00068   when possible, automatically trigger operations that give
00069   back unused memory to the system, thus reducing program footprint.
00070 */
00071 #ifndef USE_DL_PREFIX
00072    void free(void *);
00073 #else
00074    void dlfree(void *);
00075 #endif
00076 
00077 /*
00078   calloc(size_t n_elements, size_t element_size);
00079   Returns a pointer to n_elements * element_size bytes, with all locations
00080   set to zero.
00081 */
00082 #ifndef USE_DL_PREFIX
00083    void *calloc(size_t, size_t);
00084 #else
00085    void *dlcalloc(size_t, size_t);
00086 #endif
00087 
00088 /*
00089   realloc(void* p, size_t n)
00090   Returns a pointer to a chunk of size n that contains the same data
00091   as does chunk p up to the minimum of (n, p's size) bytes.
00092 
00093   The returned pointer may or may not be the same as p. The algorithm
00094   prefers extending p when possible, otherwise it employs the
00095   equivalent of a malloc-copy-free sequence.
00096 
00097   If p is null, realloc is equivalent to malloc.  
00098 
00099   If space is not available, realloc returns null, errno is set (if on
00100   ANSI) and p is NOT freed.
00101 
00102   if n is for fewer bytes than already held by p, the newly unused
00103   space is lopped off and freed if possible.  Unless the #define
00104   REALLOC_ZERO_BYTES_FREES is set, realloc with a size argument of
00105   zero (re)allocates a minimum-sized chunk.
00106 
00107   Large chunks that were internally obtained via mmap will always
00108   be reallocated using malloc-copy-free sequences unless
00109   the system supports MREMAP (currently only linux).
00110 
00111   The old unix realloc convention of allowing the last-free'd chunk
00112   to be used as an argument to realloc is not supported.
00113 */
00114 
00115 #ifndef USE_DL_PREFIX
00116    void *realloc(void *, size_t);
00117 #else
00118    void *dlrealloc(void *, size_t);
00119 #endif
00120 
00121 /*
00122   memalign(size_t alignment, size_t n);
00123   Returns a pointer to a newly allocated chunk of n bytes, aligned
00124   in accord with the alignment argument.
00125 
00126   The alignment argument should be a power of two. If the argument is
00127   not a power of two, the nearest greater power is used.
00128   8-byte alignment is guaranteed by normal malloc calls, so don't
00129   bother calling memalign with an argument of 8 or less.
00130 
00131   Overreliance on memalign is a sure way to fragment space.
00132 */
00133 
00134 #ifndef USE_DL_PREFIX
00135    void *memalign(size_t, size_t);
00136 #else
00137    void *dlmemalign(size_t, size_t);
00138 #endif
00139 
00140 /*
00141   valloc(size_t n);
00142   Allocates a page-aligned chunk of at least n bytes.
00143   Equivalent to memalign(pagesize, n), where pagesize is the page
00144   size of the system. If the pagesize is unknown, 4096 is used.
00145 */
00146 
00147 #ifndef USE_DL_PREFIX
00148    void *valloc(size_t);
00149 #else
00150    void *dlvalloc(size_t);
00151 #endif
00152 
00153 /*
00154   independent_calloc(size_t n_elements, size_t element_size, void* chunks[]);
00155 
00156   independent_calloc is similar to calloc, but instead of returning a
00157   single cleared space, it returns an array of pointers to n_elements
00158   independent elements, each of which can hold contents of size
00159   elem_size.  Each element starts out cleared, and can be
00160   independently freed, realloc'ed etc. The elements are guaranteed to
00161   be adjacently allocated (this is not guaranteed to occur with
00162   multiple callocs or mallocs), which may also improve cache locality
00163   in some applications.
00164 
00165   The "chunks" argument is optional (i.e., may be null, which is
00166   probably the most typical usage). If it is null, the returned array
00167   is itself dynamically allocated and should also be freed when it is
00168   no longer needed. Otherwise, the chunks array must be of at least
00169   n_elements in length. It is filled in with the pointers to the
00170   chunks.
00171 
00172   In either case, independent_calloc returns this pointer array, or
00173   null if the allocation failed.  If n_elements is zero and "chunks"
00174   is null, it returns a chunk representing an array with zero elements
00175   (which should be freed if not wanted).
00176 
00177   Each element must be individually freed when it is no longer
00178   needed. If you'd like to instead be able to free all at once, you
00179   should instead use regular calloc and assign pointers into this
00180   space to represent elements.  (In this case though, you cannot
00181   independently free elements.)
00182   
00183   independent_calloc simplifies and speeds up implementations of many
00184   kinds of pools.  It may also be useful when constructing large data
00185   structures that initially have a fixed number of fixed-sized nodes,
00186   but the number is not known at compile time, and some of the nodes
00187   may later need to be freed. For example:
00188 
00189   struct Node { int item; struct Node* next; };
00190   
00191   struct Node* build_list() {
00192     struct Node** pool;
00193     int n = read_number_of_nodes_needed();
00194     if (n <= 0) return 0;
00195     pool = (struct Node**)(independent_calloc(n, sizeof(struct Node), 0);
00196     if (pool == 0) return 0; // failure
00197     // organize into a linked list... 
00198     struct Node* first = pool[0];
00199     for (i = 0; i < n-1; ++i) 
00200       pool[i]->next = pool[i+1];
00201     free(pool);     // Can now free the array (or not, if it is needed later)
00202     return first;
00203   }
00204 */
00205 
00206 #ifndef USE_DL_PREFIX
00207    void **independent_calloc(size_t, size_t, void **);
00208 #else
00209    void **dlindependent_calloc(size_t, size_t, void **);
00210 #endif
00211 
00212 /*
00213   independent_comalloc(size_t n_elements, size_t sizes[], void* chunks[]);
00214 
00215   independent_comalloc allocates, all at once, a set of n_elements
00216   chunks with sizes indicated in the "sizes" array.    It returns
00217   an array of pointers to these elements, each of which can be
00218   independently freed, realloc'ed etc. The elements are guaranteed to
00219   be adjacently allocated (this is not guaranteed to occur with
00220   multiple callocs or mallocs), which may also improve cache locality
00221   in some applications.
00222 
00223   The "chunks" argument is optional (i.e., may be null). If it is null
00224   the returned array is itself dynamically allocated and should also
00225   be freed when it is no longer needed. Otherwise, the chunks array
00226   must be of at least n_elements in length. It is filled in with the
00227   pointers to the chunks.
00228 
00229   In either case, independent_comalloc returns this pointer array, or
00230   null if the allocation failed.  If n_elements is zero and chunks is
00231   null, it returns a chunk representing an array with zero elements
00232   (which should be freed if not wanted).
00233   
00234   Each element must be individually freed when it is no longer
00235   needed. If you'd like to instead be able to free all at once, you
00236   should instead use a single regular malloc, and assign pointers at
00237   particular offsets in the aggregate space. (In this case though, you 
00238   cannot independently free elements.)
00239 
00240   independent_comallac differs from independent_calloc in that each
00241   element may have a different size, and also that it does not
00242   automatically clear elements.
00243 
00244   independent_comalloc can be used to speed up allocation in cases
00245   where several structs or objects must always be allocated at the
00246   same time.  For example:
00247 
00248   struct Head { ... }
00249   struct Foot { ... }
00250 
00251   void send_message(char* msg) {
00252     int msglen = strlen(msg);
00253     size_t sizes[3] = { sizeof(struct Head), msglen, sizeof(struct Foot) };
00254     void* chunks[3];
00255     if (independent_comalloc(3, sizes, chunks) == 0)
00256       die();
00257     struct Head* head = (struct Head*)(chunks[0]);
00258     char*        body = (char*)(chunks[1]);
00259     struct Foot* foot = (struct Foot*)(chunks[2]);
00260     // ...
00261   }
00262 
00263   In general though, independent_comalloc is worth using only for
00264   larger values of n_elements. For small values, you probably won't
00265   detect enough difference from series of malloc calls to bother.
00266 
00267   Overuse of independent_comalloc can increase overall memory usage,
00268   since it cannot reuse existing noncontiguous small chunks that
00269   might be available for some of the elements.
00270 */
00271 
00272 #ifndef USE_DL_PREFIX
00273    void **independent_comalloc(size_t, size_t *, void **);
00274 #else
00275    void **dlindependent_comalloc(size_t, size_t *, void **);
00276 #endif
00277 
00278 /*
00279   pvalloc(size_t n);
00280   Equivalent to valloc(minimum-page-that-holds(n)), that is,
00281   round up n to nearest pagesize.
00282  */
00283 
00284 #ifndef USE_DL_PREFIX
00285    void *pvalloc(size_t);
00286 #else
00287    void *dlpvalloc(size_t);
00288 #endif
00289 
00290 /*
00291   cfree(void* p);
00292   Equivalent to free(p).
00293 
00294   cfree is needed/defined on some systems that pair it with calloc,
00295   for odd historical reasons (such as: cfree is used in example 
00296   code in the first edition of K&R).
00297 */
00298 
00299 #ifndef USE_DL_PREFIX
00300    void cfree(void *);
00301 #else
00302    void dlcfree(void *);
00303 #endif
00304 
00305 /*
00306   malloc_trim(size_t pad);
00307 
00308   If possible, gives memory back to the system (via negative
00309   arguments to sbrk) if there is unused memory at the `high' end of
00310   the malloc pool. You can call this after freeing large blocks of
00311   memory to potentially reduce the system-level memory requirements
00312   of a program. However, it cannot guarantee to reduce memory. Under
00313   some allocation patterns, some large free blocks of memory will be
00314   locked between two used chunks, so they cannot be given back to
00315   the system.
00316   
00317   The `pad' argument to malloc_trim represents the amount of free
00318   trailing space to leave untrimmed. If this argument is zero,
00319   only the minimum amount of memory to maintain internal data
00320   structures will be left (one page or less). Non-zero arguments
00321   can be supplied to maintain enough trailing space to service
00322   future expected allocations without having to re-obtain memory
00323   from the system.
00324   
00325   Malloc_trim returns 1 if it actually released any memory, else 0.
00326   On systems that do not support "negative sbrks", it will always
00327   return 0.
00328 */
00329 
00330 #ifndef USE_DL_PREFIX
00331    int malloc_trim(size_t);
00332 #else
00333    int dlmalloc_trim(size_t);
00334 #endif
00335 
00336 /*
00337   malloc_usable_size(void* p);
00338 
00339   Returns the number of bytes you can actually use in an allocated
00340   chunk, which may be more than you requested (although often not) due
00341   to alignment and minimum size constraints.  You can use this many
00342   bytes without worrying about overwriting other allocated
00343   objects. This is not a particularly great programming practice. But
00344   malloc_usable_size can be more useful in debugging and assertions,
00345   for example:
00346 
00347   p = malloc(n);
00348   assert(malloc_usable_size(p) >= 256);
00349 */
00350 
00351 #ifndef USE_DL_PREFIX
00352    size_t malloc_usable_size(void *);
00353 #else
00354    size_t dlmalloc_usable_size(void *);
00355 #endif
00356 
00357 /*
00358   malloc_stats();
00359   Prints on stderr the amount of space obtained from the system (both
00360   via sbrk and mmap), the maximum amount (which may be more than
00361   current if malloc_trim and/or munmap got called), and the current
00362   number of bytes allocated via malloc (or realloc, etc) but not yet
00363   freed. Note that this is the number of bytes allocated, not the
00364   number requested. It will be larger than the number requested
00365   because of alignment and bookkeeping overhead. Because it includes
00366   alignment wastage as being in use, this figure may be greater than
00367   zero even when no user-level chunks are allocated.
00368 
00369   The reported current and maximum system memory can be inaccurate if
00370   a program makes other calls to system memory allocation functions
00371   (normally sbrk) outside of malloc.
00372 
00373   malloc_stats prints only the most commonly interesting statistics.
00374   More information can be obtained by calling mallinfo.
00375 */
00376 
00377 #ifndef USE_DL_PREFIX
00378    void malloc_stats();
00379 #else
00380    void dlmalloc_stats();
00381 #endif
00382 
00383 /*
00384   mallinfo()
00385   Returns (by copy) a struct containing various summary statistics:
00386 
00387   arena:     current total non-mmapped bytes allocated from system 
00388   ordblks:   the number of free chunks 
00389   smblks:    the number of fastbin blocks (i.e., small chunks that
00390                have been freed but not use resused or consolidated)
00391   hblks:     current number of mmapped regions 
00392   hblkhd:    total bytes held in mmapped regions 
00393   usmblks:   the maximum total allocated space. This will be greater
00394                 than current total if trimming has occurred.
00395   fsmblks:   total bytes held in fastbin blocks 
00396   uordblks:  current total allocated space (normal or mmapped)
00397   fordblks:  total free space 
00398   keepcost:  the maximum number of bytes that could ideally be released
00399                back to system via malloc_trim. ("ideally" means that
00400                it ignores page restrictions etc.)
00401 
00402   The names of some of these fields don't bear much relation with
00403   their contents because this struct was defined as standard in
00404   SVID/XPG so reflects the malloc implementation that was then used
00405   in SystemV Unix.  
00406 
00407   The original SVID version of this struct, defined on most systems
00408   with mallinfo, declares all fields as ints. But some others define
00409   as unsigned long. If your system defines the fields using a type of
00410   different width than listed here, you should #include your system
00411   version before including this file.  The struct declaration is
00412   suppressed if _MALLOC_H is defined (which is done in most system
00413   malloc.h files). You can also suppress it by defining
00414   HAVE_USR_INCLUDE_MALLOC_H.
00415 
00416   Because these fields are ints, but internal bookkeeping is done with
00417   unsigned longs, the reported values may appear as negative, and may
00418   wrap around zero and thus be inaccurate.
00419 */
00420 
00421 #ifndef HAVE_USR_INCLUDE_MALLOC_H
00422 #ifndef _MALLOC_H
00423    struct mallinfo
00424    {
00425       int arena;
00426       int ordblks;
00427       int smblks;
00428       int hblks;
00429       int hblkhd;
00430       int usmblks;
00431       int fsmblks;
00432       int uordblks;
00433       int fordblks;
00434       int keepcost;
00435    };
00436 #endif
00437 #endif
00438 
00439 #ifndef USE_DL_PREFIX
00440    struct mallinfo mallinfo(void);
00441 #else
00442    struct mallinfo mallinfo(void);
00443 #endif
00444 
00445 /*
00446   mallopt(int parameter_number, int parameter_value)
00447   Sets tunable parameters The format is to provide a
00448   (parameter-number, parameter-value) pair.  mallopt then sets the
00449   corresponding parameter to the argument value if it can (i.e., so
00450   long as the value is meaningful), and returns 1 if successful else
00451   0.  SVID/XPG defines four standard param numbers for mallopt,
00452   normally defined in malloc.h.  Only one of these (M_MXFAST) is used
00453   in this malloc. The others (M_NLBLKS, M_GRAIN, M_KEEP) don't apply,
00454   so setting them has no effect. But this malloc also supports four
00455   other options in mallopt. See below for details.  Briefly, supported
00456   parameters are as follows (listed defaults are for "typical"
00457   configurations).
00458 
00459   Symbol            param #   default    allowed param values
00460   M_MXFAST          1         64         0-80  (0 disables fastbins)
00461   M_TRIM_THRESHOLD -1         128*1024   any   (-1U disables trimming)
00462   M_TOP_PAD        -2         0          any  
00463   M_MMAP_THRESHOLD -3         128*1024   any   (or 0 if no MMAP support)
00464   M_MMAP_MAX       -4         65536      any   (0 disables use of mmap)
00465 */
00466 
00467 #ifndef USE_DL_PREFIX
00468    int mallopt(int, int);
00469 #else
00470    int dlmallopt(int, int);
00471 #endif
00472 
00473 /* Descriptions of tuning options */
00474 
00475 /*
00476   M_MXFAST is the maximum request size used for "fastbins", special bins
00477   that hold returned chunks without consolidating their spaces. This
00478   enables future requests for chunks of the same size to be handled
00479   very quickly, but can increase fragmentation, and thus increase the
00480   overall memory footprint of a program.
00481 
00482   This malloc manages fastbins very conservatively yet still
00483   efficiently, so fragmentation is rarely a problem for values less
00484   than or equal to the default.  The maximum supported value of MXFAST
00485   is 80. You wouldn't want it any higher than this anyway.  Fastbins
00486   are designed especially for use with many small structs, objects or
00487   strings -- the default handles structs/objects/arrays with sizes up
00488   to 8 4byte fields, or small strings representing words, tokens,
00489   etc. Using fastbins for larger objects normally worsens
00490   fragmentation without improving speed.
00491 
00492   You can reduce M_MXFAST to 0 to disable all use of fastbins.  This
00493   causes the malloc algorithm to be a closer approximation of
00494   fifo-best-fit in all cases, not just for larger requests, but will
00495   generally cause it to be slower.
00496 */
00497 
00498 #ifndef M_MXFAST
00499 #define M_MXFAST  1
00500 #endif
00501 
00502 /*
00503   M_TRIM_THRESHOLD is the maximum amount of unused top-most memory
00504   to keep before releasing via malloc_trim in free().
00505 
00506   Automatic trimming is mainly useful in long-lived programs.
00507   Because trimming via sbrk can be slow on some systems, and can
00508   sometimes be wasteful (in cases where programs immediately
00509   afterward allocate more large chunks) the value should be high
00510   enough so that your overall system performance would improve by
00511   releasing this much memory.
00512 
00513   The trim threshold and the mmap control parameters (see below)
00514   can be traded off with one another. Trimming and mmapping are
00515   two different ways of releasing unused memory back to the
00516   system. Between these two, it is often possible to keep
00517   system-level demands of a long-lived program down to a bare
00518   minimum. For example, in one test suite of sessions measuring
00519   the XF86 X server on Linux, using a trim threshold of 128K and a
00520   mmap threshold of 192K led to near-minimal long term resource
00521   consumption.
00522 
00523   If you are using this malloc in a long-lived program, it should
00524   pay to experiment with these values.  As a rough guide, you
00525   might set to a value close to the average size of a process
00526   (program) running on your system.  Releasing this much memory
00527   would allow such a process to run in memory.  Generally, it's
00528   worth it to tune for trimming rather tham memory mapping when a
00529   program undergoes phases where several large chunks are
00530   allocated and released in ways that can reuse each other's
00531   storage, perhaps mixed with phases where there are no such
00532   chunks at all.  And in well-behaved long-lived programs,
00533   controlling release of large blocks via trimming versus mapping
00534   is usually faster.
00535 
00536   However, in most programs, these parameters serve mainly as
00537   protection against the system-level effects of carrying around
00538   massive amounts of unneeded memory. Since frequent calls to
00539   sbrk, mmap, and munmap otherwise degrade performance, the default
00540   parameters are set to relatively high values that serve only as
00541   safeguards.
00542 
00543   The trim value It must be greater than page size to have any useful
00544   effect.  To disable trimming completely, you can set to 
00545   (unsigned long)(-1)
00546 
00547   Trim settings interact with fastbin (MXFAST) settings: Unless
00548   compiled with TRIM_FASTBINS defined, automatic trimming never takes
00549   place upon freeing a chunk with size less than or equal to
00550   MXFAST. Trimming is instead delayed until subsequent freeing of
00551   larger chunks. However, you can still force an attempted trim by
00552   calling malloc_trim.
00553 
00554   Also, trimming is not generally possible in cases where
00555   the main arena is obtained via mmap.
00556 
00557   Note that the trick some people use of mallocing a huge space and
00558   then freeing it at program startup, in an attempt to reserve system
00559   memory, doesn't have the intended effect under automatic trimming,
00560   since that memory will immediately be returned to the system.
00561 */
00562 
00563 #define M_TRIM_THRESHOLD    -1
00564 
00565 /*
00566   M_TOP_PAD is the amount of extra `padding' space to allocate or
00567   retain whenever sbrk is called. It is used in two ways internally:
00568 
00569   * When sbrk is called to extend the top of the arena to satisfy
00570   a new malloc request, this much padding is added to the sbrk
00571   request.
00572 
00573   * When malloc_trim is called automatically from free(),
00574   it is used as the `pad' argument.
00575 
00576   In both cases, the actual amount of padding is rounded
00577   so that the end of the arena is always a system page boundary.
00578 
00579   The main reason for using padding is to avoid calling sbrk so
00580   often. Having even a small pad greatly reduces the likelihood
00581   that nearly every malloc request during program start-up (or
00582   after trimming) will invoke sbrk, which needlessly wastes
00583   time.
00584 
00585   Automatic rounding-up to page-size units is normally sufficient
00586   to avoid measurable overhead, so the default is 0.  However, in
00587   systems where sbrk is relatively slow, it can pay to increase
00588   this value, at the expense of carrying around more memory than
00589   the program needs.
00590 */
00591 
00592 #define M_TOP_PAD           -2
00593 
00594 /*
00595   M_MMAP_THRESHOLD is the request size threshold for using mmap()
00596   to service a request. Requests of at least this size that cannot
00597   be allocated using already-existing space will be serviced via mmap.
00598   (If enough normal freed space already exists it is used instead.)
00599 
00600   Using mmap segregates relatively large chunks of memory so that
00601   they can be individually obtained and released from the host
00602   system. A request serviced through mmap is never reused by any
00603   other request (at least not directly; the system may just so
00604   happen to remap successive requests to the same locations).
00605 
00606   Segregating space in this way has the benefits that:
00607 
00608    1. Mmapped space can ALWAYS be individually released back 
00609       to the system, which helps keep the system level memory 
00610       demands of a long-lived program low. 
00611    2. Mapped memory can never become `locked' between
00612       other chunks, as can happen with normally allocated chunks, which
00613       means that even trimming via malloc_trim would not release them.
00614    3. On some systems with "holes" in address spaces, mmap can obtain
00615       memory that sbrk cannot.
00616 
00617   However, it has the disadvantages that:
00618 
00619    1. The space cannot be reclaimed, consolidated, and then
00620       used to service later requests, as happens with normal chunks.
00621    2. It can lead to more wastage because of mmap page alignment
00622       requirements
00623    3. It causes malloc performance to be more dependent on host
00624       system memory management support routines.
00625 
00626   The advantages of mmap nearly always outweigh disadvantages for
00627   "large" chunks, but the value of "large" varies across systems.  The
00628   default is an empirically derived value that works well in most
00629   systems.
00630 */
00631 
00632 #define M_MMAP_THRESHOLD    -3
00633 
00634 /*
00635   M_MMAP_MAX is the maximum number of requests to simultaneously
00636   service using mmap. This parameter exists because
00637   some systems have a limited number of internal tables for
00638   use by mmap, and using more than a few of them may degrade
00639   performance.
00640 
00641   The default is set to a value that serves only as a safeguard.
00642   Setting to 0 disables use of mmap for servicing large requests.  If
00643   mmap is not supported on a system, the default value is 0, and
00644   attempts to set it to non-zero values in mallopt will fail.
00645 */
00646 
00647 #define M_MMAP_MAX          -4
00648 
00649 /* Unused SVID2/XPG mallopt options, listed for completeness */
00650 
00651 #ifndef M_NBLKS
00652 #define M_NLBLKS  2             /* UNUSED in this malloc */
00653 #endif
00654 #ifndef M_GRAIN
00655 #define M_GRAIN   3             /* UNUSED in this malloc */
00656 #endif
00657 #ifndef M_KEEP
00658 #define M_KEEP    4             /* UNUSED in this malloc */
00659 #endif
00660 
00661 /* 
00662   Some malloc.h's declare alloca, even though it is not part of malloc.
00663 */
00664 
00665 #ifndef _ALLOCA_H
00666    extern void *alloca(size_t);
00667 #endif
00668 
00669 #ifdef __cplusplus
00670 };                              /* end of extern "C" */
00671 #endif
00672 
00673 #endif /* MALLOC_270_H */

Generated on Wed Mar 22 20:36:33 2006 for ndk by  doxygen 1.4.4