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 */