own_malloc.h
上传用户:wealth48
上传日期:2022-06-24
资源大小:1701k
文件大小:24k
源码类别:

uCOS

开发平台:

C/C++

  1. /*
  2.   Default header file for malloc-2.7.2, written by Doug Lea
  3.   and released to the public domain.  Use, modify, and redistribute
  4.   this code without permission or acknowledgement in any way you wish.
  5.   Send questions, comments, complaints, performance data, etc to
  6.   dl@cs.oswego.edu.
  7.  
  8.   last update: Sun Feb 25 18:38:11 2001  Doug Lea  (dl at gee)
  9.   This header is for ANSI C/C++ only.  You can set either of
  10.   the following #defines before including:
  11.   * If USE_DL_PREFIX is defined, it is assumed that malloc.c 
  12.     was also compiled with this option, so all routines
  13.     have names starting with "dl".
  14.   * If HAVE_USR_INCLUDE_MALLOC_H is defined, it is assumed that this
  15.     file will be #included AFTER <malloc.h>. This is needed only if
  16.     your system defines a struct mallinfo that is incompatible with the
  17.     standard one declared here.  Otherwise, you can include this file
  18.     INSTEAD of your system system <malloc.h>.  At least on ANSI, all
  19.     declarations should be compatible with system versions
  20. */
  21. #ifndef MALLOC_270_H
  22. #define MALLOC_270_H
  23. #ifdef __cplusplus
  24. extern "C" {
  25. #endif
  26. #include <stddef.h>   /* for size_t */
  27. /*
  28.   malloc(size_t n)
  29.   Returns a pointer to a newly allocated chunk of at least n bytes, or
  30.   null if no space is available. Additionally, on failure, errno is
  31.   set to ENOMEM on ANSI C systems.
  32.   If n is zero, malloc returns a minimum-sized chunk. The minimum size
  33.   is 16 bytes on most 32bit systems, and either 24 or 32 bytes on
  34.   64bit systems, depending on internal size and alignment restrictions.
  35.   On most systems, size_t is an unsigned type.  Calls with values of n
  36.   that appear "negative" when signed are interpreted as requests for
  37.   huge amounts of space, which will most often fail.
  38.   The maximum allowed value of n differs across systems, but is in all
  39.   cases less (typically by 8K) than the maximum representable value of
  40.   a size_t. Requests greater than this value result in failure.
  41. */
  42. #ifndef USE_DL_PREFIX
  43. void*  malloc(size_t);
  44. #else
  45. void*  dlmalloc(size_t);
  46. #endif
  47. /*
  48.   free(void* p)
  49.   Releases the chunk of memory pointed to by p, that had been previously
  50.   allocated using malloc or a related routine such as realloc.
  51.   It has no effect if p is null. It can have arbitrary (and bad!)
  52.   effects if p has already been freed or was not obtained via malloc.
  53.   Unless disabled using mallopt, freeing very large spaces will,
  54.   when possible, automatically trigger operations that give
  55.   back unused memory to the system, thus reducing program footprint.
  56. */
  57. #ifndef USE_DL_PREFIX
  58. void     free(void*);
  59. #else
  60. void     dlfree(void*);
  61. #endif
  62. /*
  63.   calloc(size_t n_elements, size_t element_size);
  64.   Returns a pointer to n_elements * element_size bytes, with all locations
  65.   set to zero.
  66. */
  67. #ifndef USE_DL_PREFIX
  68. void*  calloc(size_t, size_t);
  69. #else
  70. void*  dlcalloc(size_t, size_t);
  71. #endif
  72. /*
  73.   realloc(void* p, size_t n)
  74.   Returns a pointer to a chunk of size n that contains the same data
  75.   as does chunk p up to the minimum of (n, p's size) bytes.
  76.   The returned pointer may or may not be the same as p. The algorithm
  77.   prefers extending p when possible, otherwise it employs the
  78.   equivalent of a malloc-copy-free sequence.
  79.   If p is null, realloc is equivalent to malloc.  
  80.   If space is not available, realloc returns null, errno is set (if on
  81.   ANSI) and p is NOT freed.
  82.   if n is for fewer bytes than already held by p, the newly unused
  83.   space is lopped off and freed if possible.  Unless the #define
  84.   REALLOC_ZERO_BYTES_FREES is set, realloc with a size argument of
  85.   zero (re)allocates a minimum-sized chunk.
  86.   Large chunks that were internally obtained via mmap will always
  87.   be reallocated using malloc-copy-free sequences unless
  88.   the system supports MREMAP (currently only linux).
  89.   The old unix realloc convention of allowing the last-free'd chunk
  90.   to be used as an argument to realloc is not supported.
  91. */
  92. #ifndef USE_DL_PREFIX
  93. void*  realloc(void*, size_t);
  94. #else
  95. void*  dlrealloc(void*, size_t);
  96. #endif
  97. /*
  98.   memalign(size_t alignment, size_t n);
  99.   Returns a pointer to a newly allocated chunk of n bytes, aligned
  100.   in accord with the alignment argument.
  101.   The alignment argument should be a power of two. If the argument is
  102.   not a power of two, the nearest greater power is used.
  103.   8-byte alignment is guaranteed by normal malloc calls, so don't
  104.   bother calling memalign with an argument of 8 or less.
  105.   Overreliance on memalign is a sure way to fragment space.
  106. */
  107. #ifndef USE_DL_PREFIX
  108. void*  memalign(size_t, size_t);
  109. #else
  110. void*  dlmemalign(size_t, size_t);
  111. #endif
  112. /*
  113.   valloc(size_t n);
  114.   Allocates a page-aligned chunk of at least n bytes.
  115.   Equivalent to memalign(pagesize, n), where pagesize is the page
  116.   size of the system. If the pagesize is unknown, 4096 is used.
  117. */
  118. #ifndef USE_DL_PREFIX
  119. void*  valloc(size_t);
  120. #else
  121. void*  dlvalloc(size_t);
  122. #endif
  123. #if 0
  124. /*
  125.   independent_calloc(size_t n_elements, size_t element_size, void* chunks[]);
  126.   independent_calloc is similar to calloc, but instead of returning a
  127.   single cleared space, it returns an array of pointers to n_elements
  128.   independent elements, each of which can hold contents of size
  129.   elem_size.  Each element starts out cleared, and can be
  130.   independently freed, realloc'ed etc. The elements are guaranteed to
  131.   be adjacently allocated (this is not guaranteed to occur with
  132.   multiple callocs or mallocs), which may also improve cache locality
  133.   in some applications.
  134.   The "chunks" argument is optional (i.e., may be null, which is
  135.   probably the most typical usage). If it is null, the returned array
  136.   is itself dynamically allocated and should also be freed when it is
  137.   no longer needed. Otherwise, the chunks array must be of at least
  138.   n_elements in length. It is filled in with the pointers to the
  139.   chunks.
  140.   In either case, independent_calloc returns this pointer array, or
  141.   null if the allocation failed.  If n_elements is zero and "chunks"
  142.   is null, it returns a chunk representing an array with zero elements
  143.   (which should be freed if not wanted).
  144.   Each element must be individually freed when it is no longer
  145.   needed. If you'd like to instead be able to free all at once, you
  146.   should instead use regular calloc and assign pointers into this
  147.   space to represent elements.  (In this case though, you cannot
  148.   independently free elements.)
  149.   
  150.   independent_calloc simplifies and speeds up implementations of many
  151.   kinds of pools.  It may also be useful when constructing large data
  152.   structures that initially have a fixed number of fixed-sized nodes,
  153.   but the number is not known at compile time, and some of the nodes
  154.   may later need to be freed. For example:
  155.   struct Node { int item; struct Node* next; };
  156.   
  157.   struct Node* build_list() {
  158.     struct Node** pool;
  159.     int n = read_number_of_nodes_needed();
  160.     if (n <= 0) return 0;
  161.     pool = (struct Node**)(independent_calloc(n, sizeof(struct Node), 0);
  162.     if (pool == 0) return 0; // failure
  163.     // organize into a linked list... 
  164.     struct Node* first = pool[0];
  165.     for (i = 0; i < n-1; ++i) 
  166.       pool[i]->next = pool[i+1];
  167.     free(pool);     // Can now free the array (or not, if it is needed later)
  168.     return first;
  169.   }
  170. */
  171. #ifndef USE_DL_PREFIX
  172. void** independent_calloc(size_t, size_t, void**);
  173. #else
  174. void** dlindependent_calloc(size_t, size_t, void**);
  175. #endif
  176. /*
  177.   independent_comalloc(size_t n_elements, size_t sizes[], void* chunks[]);
  178.   independent_comalloc allocates, all at once, a set of n_elements
  179.   chunks with sizes indicated in the "sizes" array.    It returns
  180.   an array of pointers to these elements, each of which can be
  181.   independently freed, realloc'ed etc. The elements are guaranteed to
  182.   be adjacently allocated (this is not guaranteed to occur with
  183.   multiple callocs or mallocs), which may also improve cache locality
  184.   in some applications.
  185.   The "chunks" argument is optional (i.e., may be null). If it is null
  186.   the returned array is itself dynamically allocated and should also
  187.   be freed when it is no longer needed. Otherwise, the chunks array
  188.   must be of at least n_elements in length. It is filled in with the
  189.   pointers to the chunks.
  190.   In either case, independent_comalloc returns this pointer array, or
  191.   null if the allocation failed.  If n_elements is zero and chunks is
  192.   null, it returns a chunk representing an array with zero elements
  193.   (which should be freed if not wanted).
  194.   
  195.   Each element must be individually freed when it is no longer
  196.   needed. If you'd like to instead be able to free all at once, you
  197.   should instead use a single regular malloc, and assign pointers at
  198.   particular offsets in the aggregate space. (In this case though, you 
  199.   cannot independently free elements.)
  200.   independent_comallac differs from independent_calloc in that each
  201.   element may have a different size, and also that it does not
  202.   automatically clear elements.
  203.   independent_comalloc can be used to speed up allocation in cases
  204.   where several structs or objects must always be allocated at the
  205.   same time.  For example:
  206.   struct Head { ... }
  207.   struct Foot { ... }
  208.   void send_message(char* msg) {
  209.     int msglen = strlen(msg);
  210.     size_t sizes[3] = { sizeof(struct Head), msglen, sizeof(struct Foot) };
  211.     void* chunks[3];
  212.     if (independent_comalloc(3, sizes, chunks) == 0)
  213.       die();
  214.     struct Head* head = (struct Head*)(chunks[0]);
  215.     char*        body = (char*)(chunks[1]);
  216.     struct Foot* foot = (struct Foot*)(chunks[2]);
  217.     // ...
  218.   }
  219.   In general though, independent_comalloc is worth using only for
  220.   larger values of n_elements. For small values, you probably won't
  221.   detect enough difference from series of malloc calls to bother.
  222.   Overuse of independent_comalloc can increase overall memory usage,
  223.   since it cannot reuse existing noncontiguous small chunks that
  224.   might be available for some of the elements.
  225. */
  226. #ifndef USE_DL_PREFIX
  227. void** independent_comalloc(size_t, size_t*, void**);
  228. #else
  229. void** dlindependent_comalloc(size_t, size_t*, void**);
  230. #endif
  231. /*
  232.   pvalloc(size_t n);
  233.   Equivalent to valloc(minimum-page-that-holds(n)), that is,
  234.   round up n to nearest pagesize.
  235.  */
  236. #ifndef USE_DL_PREFIX
  237. void*  pvalloc(size_t);
  238. #else
  239. void*  dlpvalloc(size_t);
  240. #endif
  241. /*
  242.   cfree(void* p);
  243.   Equivalent to free(p).
  244.   cfree is needed/defined on some systems that pair it with calloc,
  245.   for odd historical reasons (such as: cfree is used in example 
  246.   code in the first edition of K&R).
  247. */
  248. #ifndef USE_DL_PREFIX
  249. void     cfree(void*);
  250. #else
  251. void     dlcfree(void*);
  252. #endif
  253. /*
  254.   malloc_trim(size_t pad);
  255.   If possible, gives memory back to the system (via negative
  256.   arguments to sbrk) if there is unused memory at the `high' end of
  257.   the malloc pool. You can call this after freeing large blocks of
  258.   memory to potentially reduce the system-level memory requirements
  259.   of a program. However, it cannot guarantee to reduce memory. Under
  260.   some allocation patterns, some large free blocks of memory will be
  261.   locked between two used chunks, so they cannot be given back to
  262.   the system.
  263.   
  264.   The `pad' argument to malloc_trim represents the amount of free
  265.   trailing space to leave untrimmed. If this argument is zero,
  266.   only the minimum amount of memory to maintain internal data
  267.   structures will be left (one page or less). Non-zero arguments
  268.   can be supplied to maintain enough trailing space to service
  269.   future expected allocations without having to re-obtain memory
  270.   from the system.
  271.   
  272.   Malloc_trim returns 1 if it actually released any memory, else 0.
  273.   On systems that do not support "negative sbrks", it will always
  274.   return 0.
  275. */
  276. #ifndef USE_DL_PREFIX
  277. int      malloc_trim(size_t);
  278. #else
  279. int      dlmalloc_trim(size_t);
  280. #endif
  281. /*
  282.   malloc_usable_size(void* p);
  283.   Returns the number of bytes you can actually use in an allocated
  284.   chunk, which may be more than you requested (although often not) due
  285.   to alignment and minimum size constraints.  You can use this many
  286.   bytes without worrying about overwriting other allocated
  287.   objects. This is not a particularly great programming practice. But
  288.   malloc_usable_size can be more useful in debugging and assertions,
  289.   for example:
  290.   p = malloc(n);
  291.   assert(malloc_usable_size(p) >= 256);
  292. */
  293. #ifndef USE_DL_PREFIX
  294. size_t   malloc_usable_size(void*);
  295. #else
  296. size_t   dlmalloc_usable_size(void*);
  297. #endif
  298. /*
  299.   malloc_stats();
  300.   Prints on stderr the amount of space obtained from the system (both
  301.   via sbrk and mmap), the maximum amount (which may be more than
  302.   current if malloc_trim and/or munmap got called), and the current
  303.   number of bytes allocated via malloc (or realloc, etc) but not yet
  304.   freed. Note that this is the number of bytes allocated, not the
  305.   number requested. It will be larger than the number requested
  306.   because of alignment and bookkeeping overhead. Because it includes
  307.   alignment wastage as being in use, this figure may be greater than
  308.   zero even when no user-level chunks are allocated.
  309.   The reported current and maximum system memory can be inaccurate if
  310.   a program makes other calls to system memory allocation functions
  311.   (normally sbrk) outside of malloc.
  312.   malloc_stats prints only the most commonly interesting statistics.
  313.   More information can be obtained by calling mallinfo.
  314. */
  315. #ifndef USE_DL_PREFIX
  316. void     malloc_stats();
  317. #else
  318. void     dlmalloc_stats();
  319. #endif
  320. /*
  321.   mallinfo()
  322.   Returns (by copy) a struct containing various summary statistics:
  323.   arena:     current total non-mmapped bytes allocated from system 
  324.   ordblks:   the number of free chunks 
  325.   smblks:    the number of fastbin blocks (i.e., small chunks that
  326.                have been freed but not use resused or consolidated)
  327.   hblks:     current number of mmapped regions 
  328.   hblkhd:    total bytes held in mmapped regions 
  329.   usmblks:   the maximum total allocated space. This will be greater
  330.                 than current total if trimming has occurred.
  331.   fsmblks:   total bytes held in fastbin blocks 
  332.   uordblks:  current total allocated space (normal or mmapped)
  333.   fordblks:  total free space 
  334.   keepcost:  the maximum number of bytes that could ideally be released
  335.                back to system via malloc_trim. ("ideally" means that
  336.                it ignores page restrictions etc.)
  337.   The names of some of these fields don't bear much relation with
  338.   their contents because this struct was defined as standard in
  339.   SVID/XPG so reflects the malloc implementation that was then used
  340.   in SystemV Unix.  
  341.   The original SVID version of this struct, defined on most systems
  342.   with mallinfo, declares all fields as ints. But some others define
  343.   as unsigned long. If your system defines the fields using a type of
  344.   different width than listed here, you should #include your system
  345.   version before including this file.  The struct declaration is
  346.   suppressed if _MALLOC_H is defined (which is done in most system
  347.   malloc.h files). You can also suppress it by defining
  348.   HAVE_USR_INCLUDE_MALLOC_H.
  349.   Because these fields are ints, but internal bookkeeping is done with
  350.   unsigned longs, the reported values may appear as negative, and may
  351.   wrap around zero and thus be inaccurate.
  352. */
  353. #ifndef HAVE_USR_INCLUDE_MALLOC_H
  354. #ifndef _MALLOC_H
  355. struct mallinfo {
  356.   int arena;    
  357.   int ordblks;  
  358.   int smblks;   
  359.   int hblks;    
  360.   int hblkhd;   
  361.   int usmblks;  
  362.   int fsmblks;  
  363.   int uordblks; 
  364.   int fordblks; 
  365.   int keepcost; 
  366. };
  367. #endif
  368. #endif
  369. #ifndef USE_DL_PREFIX
  370. struct mallinfo mallinfo(void);
  371. #else
  372. struct mallinfo mallinfo(void);
  373. #endif
  374. /*
  375.   mallopt(int parameter_number, int parameter_value)
  376.   Sets tunable parameters The format is to provide a
  377.   (parameter-number, parameter-value) pair.  mallopt then sets the
  378.   corresponding parameter to the argument value if it can (i.e., so
  379.   long as the value is meaningful), and returns 1 if successful else
  380.   0.  SVID/XPG defines four standard param numbers for mallopt,
  381.   normally defined in malloc.h.  Only one of these (M_MXFAST) is used
  382.   in this malloc. The others (M_NLBLKS, M_GRAIN, M_KEEP) don't apply,
  383.   so setting them has no effect. But this malloc also supports four
  384.   other options in mallopt. See below for details.  Briefly, supported
  385.   parameters are as follows (listed defaults are for "typical"
  386.   configurations).
  387.   Symbol            param #   default    allowed param values
  388.   M_MXFAST          1         64         0-80  (0 disables fastbins)
  389.   M_TRIM_THRESHOLD -1         128*1024   any   (-1U disables trimming)
  390.   M_TOP_PAD        -2         0          any  
  391.   M_MMAP_THRESHOLD -3         128*1024   any   (or 0 if no MMAP support)
  392.   M_MMAP_MAX       -4         65536      any   (0 disables use of mmap)
  393. */
  394. #ifndef USE_DL_PREFIX
  395. int  mallopt(int, int);
  396. #else
  397. int  dlmallopt(int, int);
  398. #endif
  399. #endif
  400. /* Descriptions of tuning options */
  401. /*
  402.   M_MXFAST is the maximum request size used for "fastbins", special bins
  403.   that hold returned chunks without consolidating their spaces. This
  404.   enables future requests for chunks of the same size to be handled
  405.   very quickly, but can increase fragmentation, and thus increase the
  406.   overall memory footprint of a program.
  407.   This malloc manages fastbins very conservatively yet still
  408.   efficiently, so fragmentation is rarely a problem for values less
  409.   than or equal to the default.  The maximum supported value of MXFAST
  410.   is 80. You wouldn't want it any higher than this anyway.  Fastbins
  411.   are designed especially for use with many small structs, objects or
  412.   strings -- the default handles structs/objects/arrays with sizes up
  413.   to 8 4byte fields, or small strings representing words, tokens,
  414.   etc. Using fastbins for larger objects normally worsens
  415.   fragmentation without improving speed.
  416.   You can reduce M_MXFAST to 0 to disable all use of fastbins.  This
  417.   causes the malloc algorithm to be a closer approximation of
  418.   fifo-best-fit in all cases, not just for larger requests, but will
  419.   generally cause it to be slower.
  420. */
  421. #ifndef M_MXFAST
  422. #define M_MXFAST  1
  423. #endif
  424. /*
  425.   M_TRIM_THRESHOLD is the maximum amount of unused top-most memory
  426.   to keep before releasing via malloc_trim in free().
  427.   Automatic trimming is mainly useful in long-lived programs.
  428.   Because trimming via sbrk can be slow on some systems, and can
  429.   sometimes be wasteful (in cases where programs immediately
  430.   afterward allocate more large chunks) the value should be high
  431.   enough so that your overall system performance would improve by
  432.   releasing this much memory.
  433.   The trim threshold and the mmap control parameters (see below)
  434.   can be traded off with one another. Trimming and mmapping are
  435.   two different ways of releasing unused memory back to the
  436.   system. Between these two, it is often possible to keep
  437.   system-level demands of a long-lived program down to a bare
  438.   minimum. For example, in one test suite of sessions measuring
  439.   the XF86 X server on Linux, using a trim threshold of 128K and a
  440.   mmap threshold of 192K led to near-minimal long term resource
  441.   consumption.
  442.   If you are using this malloc in a long-lived program, it should
  443.   pay to experiment with these values.  As a rough guide, you
  444.   might set to a value close to the average size of a process
  445.   (program) running on your system.  Releasing this much memory
  446.   would allow such a process to run in memory.  Generally, it's
  447.   worth it to tune for trimming rather tham memory mapping when a
  448.   program undergoes phases where several large chunks are
  449.   allocated and released in ways that can reuse each other's
  450.   storage, perhaps mixed with phases where there are no such
  451.   chunks at all.  And in well-behaved long-lived programs,
  452.   controlling release of large blocks via trimming versus mapping
  453.   is usually faster.
  454.   However, in most programs, these parameters serve mainly as
  455.   protection against the system-level effects of carrying around
  456.   massive amounts of unneeded memory. Since frequent calls to
  457.   sbrk, mmap, and munmap otherwise degrade performance, the default
  458.   parameters are set to relatively high values that serve only as
  459.   safeguards.
  460.   The trim value It must be greater than page size to have any useful
  461.   effect.  To disable trimming completely, you can set to 
  462.   (unsigned long)(-1)
  463.   Trim settings interact with fastbin (MXFAST) settings: Unless
  464.   compiled with TRIM_FASTBINS defined, automatic trimming never takes
  465.   place upon freeing a chunk with size less than or equal to
  466.   MXFAST. Trimming is instead delayed until subsequent freeing of
  467.   larger chunks. However, you can still force an attempted trim by
  468.   calling malloc_trim.
  469.   Also, trimming is not generally possible in cases where
  470.   the main arena is obtained via mmap.
  471.   Note that the trick some people use of mallocing a huge space and
  472.   then freeing it at program startup, in an attempt to reserve system
  473.   memory, doesn't have the intended effect under automatic trimming,
  474.   since that memory will immediately be returned to the system.
  475. */
  476. #define M_TRIM_THRESHOLD    -1
  477. /*
  478.   M_TOP_PAD is the amount of extra `padding' space to allocate or
  479.   retain whenever sbrk is called. It is used in two ways internally:
  480.   * When sbrk is called to extend the top of the arena to satisfy
  481.   a new malloc request, this much padding is added to the sbrk
  482.   request.
  483.   * When malloc_trim is called automatically from free(),
  484.   it is used as the `pad' argument.
  485.   In both cases, the actual amount of padding is rounded
  486.   so that the end of the arena is always a system page boundary.
  487.   The main reason for using padding is to avoid calling sbrk so
  488.   often. Having even a small pad greatly reduces the likelihood
  489.   that nearly every malloc request during program start-up (or
  490.   after trimming) will invoke sbrk, which needlessly wastes
  491.   time.
  492.   Automatic rounding-up to page-size units is normally sufficient
  493.   to avoid measurable overhead, so the default is 0.  However, in
  494.   systems where sbrk is relatively slow, it can pay to increase
  495.   this value, at the expense of carrying around more memory than
  496.   the program needs.
  497. */
  498. #define M_TOP_PAD           -2
  499. /*
  500.   M_MMAP_THRESHOLD is the request size threshold for using mmap()
  501.   to service a request. Requests of at least this size that cannot
  502.   be allocated using already-existing space will be serviced via mmap.
  503.   (If enough normal freed space already exists it is used instead.)
  504.   Using mmap segregates relatively large chunks of memory so that
  505.   they can be individually obtained and released from the host
  506.   system. A request serviced through mmap is never reused by any
  507.   other request (at least not directly; the system may just so
  508.   happen to remap successive requests to the same locations).
  509.   Segregating space in this way has the benefits that:
  510.    1. Mmapped space can ALWAYS be individually released back 
  511.       to the system, which helps keep the system level memory 
  512.       demands of a long-lived program low. 
  513.    2. Mapped memory can never become `locked' between
  514.       other chunks, as can happen with normally allocated chunks, which
  515.       means that even trimming via malloc_trim would not release them.
  516.    3. On some systems with "holes" in address spaces, mmap can obtain
  517.       memory that sbrk cannot.
  518.   However, it has the disadvantages that:
  519.    1. The space cannot be reclaimed, consolidated, and then
  520.       used to service later requests, as happens with normal chunks.
  521.    2. It can lead to more wastage because of mmap page alignment
  522.       requirements
  523.    3. It causes malloc performance to be more dependent on host
  524.       system memory management support routines.
  525.   The advantages of mmap nearly always outweigh disadvantages for
  526.   "large" chunks, but the value of "large" varies across systems.  The
  527.   default is an empirically derived value that works well in most
  528.   systems.
  529. */
  530. #define M_MMAP_THRESHOLD    -3
  531. /*
  532.   M_MMAP_MAX is the maximum number of requests to simultaneously
  533.   service using mmap. This parameter exists because
  534.   some systems have a limited number of internal tables for
  535.   use by mmap, and using more than a few of them may degrade
  536.   performance.
  537.   The default is set to a value that serves only as a safeguard.
  538.   Setting to 0 disables use of mmap for servicing large requests.  If
  539.   mmap is not supported on a system, the default value is 0, and
  540.   attempts to set it to non-zero values in mallopt will fail.
  541. */
  542. #define M_MMAP_MAX          -4
  543. /* Unused SVID2/XPG mallopt options, listed for completeness */
  544. #ifndef M_NBLKS
  545. #define M_NLBLKS  2    /* UNUSED in this malloc */
  546. #endif
  547. #ifndef M_GRAIN
  548. #define M_GRAIN   3    /* UNUSED in this malloc */
  549. #endif
  550. #ifndef M_KEEP
  551. #define M_KEEP    4    /* UNUSED in this malloc */
  552. #endif
  553. /* 
  554.   Some malloc.h's declare alloca, even though it is not part of malloc.
  555. */
  556. #ifndef _ALLOCA_H
  557. extern void* alloca(size_t);
  558. #endif
  559. #ifdef __cplusplus
  560. };  /* end of extern "C" */
  561. #endif
  562. int ucos2_malloc_init(void);
  563. #endif /* MALLOC_270_H */