OSDN Git Service

next portion of libc_hidden_proto removal
[uclinux-h8/uClibc.git] / libc / stdlib / malloc-standard / malloc.h
1 /*
2   This is a version (aka dlmalloc) of malloc/free/realloc written by
3   Doug Lea and released to the public domain.  Use, modify, and
4   redistribute this code without permission or acknowledgement in any
5   way you wish.  Send questions, comments, complaints, performance
6   data, etc to dl@cs.oswego.edu
7
8   VERSION 2.7.2 Sat Aug 17 09:07:30 2002  Doug Lea  (dl at gee)
9
10   Note: There may be an updated version of this malloc obtainable at
11            ftp://gee.cs.oswego.edu/pub/misc/malloc.c
12   Check before installing!
13
14   Hacked up for uClibc by Erik Andersen <andersen@codepoet.org>
15 */
16
17 #include <features.h>
18 #include <stddef.h>
19 #include <unistd.h>
20 #include <errno.h>
21 #include <string.h>
22 #include <malloc.h>
23 #include <stdlib.h>
24 #include <sys/mman.h>
25 #include <bits/uClibc_mutex.h>
26
27 /* libc_hidden_proto(mmap) */
28 libc_hidden_proto(sysconf)
29 /* libc_hidden_proto(sbrk) */
30 /* libc_hidden_proto(abort) */
31
32
33 __UCLIBC_MUTEX_EXTERN(__malloc_lock);
34 #define __MALLOC_LOCK           __UCLIBC_MUTEX_LOCK(__malloc_lock)
35 #define __MALLOC_UNLOCK         __UCLIBC_MUTEX_UNLOCK(__malloc_lock)
36
37
38
39 /*
40   MALLOC_ALIGNMENT is the minimum alignment for malloc'ed chunks.
41   It must be a power of two at least 2 * (sizeof(size_t)), even on machines
42   for which smaller alignments would suffice. It may be defined as
43   larger than this though. Note however that code and data structures
44   are optimized for the case of 8-byte alignment.
45 */
46 #ifndef MALLOC_ALIGNMENT
47 #define MALLOC_ALIGNMENT       (2 * (sizeof(size_t)))
48 #endif
49
50 /* The corresponding bit mask value */
51 #define MALLOC_ALIGN_MASK      (MALLOC_ALIGNMENT - 1)
52
53 /*
54   TRIM_FASTBINS controls whether free() of a very small chunk can
55   immediately lead to trimming. Setting to true (1) can reduce memory
56   footprint, but will almost always slow down programs that use a lot
57   of small chunks.
58
59   Define this only if you are willing to give up some speed to more
60   aggressively reduce system-level memory footprint when releasing
61   memory in programs that use many small chunks.  You can get
62   essentially the same effect by setting MXFAST to 0, but this can
63   lead to even greater slowdowns in programs using many small chunks.
64   TRIM_FASTBINS is an in-between compile-time option, that disables
65   only those chunks bordering topmost memory from being placed in
66   fastbins.
67 */
68 #ifndef TRIM_FASTBINS
69 #define TRIM_FASTBINS  0
70 #endif
71
72
73 /*
74   MORECORE-related declarations. By default, rely on sbrk
75 */
76
77
78 /*
79   MORECORE is the name of the routine to call to obtain more memory
80   from the system.  See below for general guidance on writing
81   alternative MORECORE functions, as well as a version for WIN32 and a
82   sample version for pre-OSX macos.
83 */
84 #ifndef MORECORE
85 #define MORECORE sbrk
86 #endif
87
88 /*
89   MORECORE_FAILURE is the value returned upon failure of MORECORE
90   as well as mmap. Since it cannot be an otherwise valid memory address,
91   and must reflect values of standard sys calls, you probably ought not
92   try to redefine it.
93 */
94 #ifndef MORECORE_FAILURE
95 #define MORECORE_FAILURE (-1)
96 #endif
97
98 /*
99   If MORECORE_CONTIGUOUS is true, take advantage of fact that
100   consecutive calls to MORECORE with positive arguments always return
101   contiguous increasing addresses.  This is true of unix sbrk.  Even
102   if not defined, when regions happen to be contiguous, malloc will
103   permit allocations spanning regions obtained from different
104   calls. But defining this when applicable enables some stronger
105   consistency checks and space efficiencies.
106 */
107 #ifndef MORECORE_CONTIGUOUS
108 #define MORECORE_CONTIGUOUS 1
109 #endif
110
111 /*
112    MMAP_AS_MORECORE_SIZE is the minimum mmap size argument to use if
113    sbrk fails, and mmap is used as a backup (which is done only if
114    HAVE_MMAP).  The value must be a multiple of page size.  This
115    backup strategy generally applies only when systems have "holes" in
116    address space, so sbrk cannot perform contiguous expansion, but
117    there is still space available on system.  On systems for which
118    this is known to be useful (i.e. most linux kernels), this occurs
119    only when programs allocate huge amounts of memory.  Between this,
120    and the fact that mmap regions tend to be limited, the size should
121    be large, to avoid too many mmap calls and thus avoid running out
122    of kernel resources.
123 */
124 #ifndef MMAP_AS_MORECORE_SIZE
125 #define MMAP_AS_MORECORE_SIZE (1024 * 1024)
126 #endif
127
128 /*
129   The system page size. To the extent possible, this malloc manages
130   memory from the system in page-size units.  Note that this value is
131   cached during initialization into a field of malloc_state. So even
132   if malloc_getpagesize is a function, it is only called once.
133
134   The following mechanics for getpagesize were adapted from bsd/gnu
135   getpagesize.h. If none of the system-probes here apply, a value of
136   4096 is used, which should be OK: If they don't apply, then using
137   the actual value probably doesn't impact performance.
138 */
139 #ifndef malloc_getpagesize
140 #  include <unistd.h>
141 #  define malloc_getpagesize sysconf(_SC_PAGESIZE)
142 #else /* just guess */
143 #  define malloc_getpagesize (4096)
144 #endif
145
146
147 /* mallopt tuning options */
148
149 /*
150   M_MXFAST is the maximum request size used for "fastbins", special bins
151   that hold returned chunks without consolidating their spaces. This
152   enables future requests for chunks of the same size to be handled
153   very quickly, but can increase fragmentation, and thus increase the
154   overall memory footprint of a program.
155
156   This malloc manages fastbins very conservatively yet still
157   efficiently, so fragmentation is rarely a problem for values less
158   than or equal to the default.  The maximum supported value of MXFAST
159   is 80. You wouldn't want it any higher than this anyway.  Fastbins
160   are designed especially for use with many small structs, objects or
161   strings -- the default handles structs/objects/arrays with sizes up
162   to 16 4byte fields, or small strings representing words, tokens,
163   etc. Using fastbins for larger objects normally worsens
164   fragmentation without improving speed.
165
166   M_MXFAST is set in REQUEST size units. It is internally used in
167   chunksize units, which adds padding and alignment.  You can reduce
168   M_MXFAST to 0 to disable all use of fastbins.  This causes the malloc
169   algorithm to be a closer approximation of fifo-best-fit in all cases,
170   not just for larger requests, but will generally cause it to be
171   slower.
172 */
173
174
175 /* M_MXFAST is a standard SVID/XPG tuning option, usually listed in malloc.h */
176 #ifndef M_MXFAST
177 #define M_MXFAST            1
178 #endif
179
180 #ifndef DEFAULT_MXFAST
181 #define DEFAULT_MXFAST     64
182 #endif
183
184
185 /*
186   M_TRIM_THRESHOLD is the maximum amount of unused top-most memory
187   to keep before releasing via malloc_trim in free().
188
189   Automatic trimming is mainly useful in long-lived programs.
190   Because trimming via sbrk can be slow on some systems, and can
191   sometimes be wasteful (in cases where programs immediately
192   afterward allocate more large chunks) the value should be high
193   enough so that your overall system performance would improve by
194   releasing this much memory.
195
196   The trim threshold and the mmap control parameters (see below)
197   can be traded off with one another. Trimming and mmapping are
198   two different ways of releasing unused memory back to the
199   system. Between these two, it is often possible to keep
200   system-level demands of a long-lived program down to a bare
201   minimum. For example, in one test suite of sessions measuring
202   the XF86 X server on Linux, using a trim threshold of 128K and a
203   mmap threshold of 192K led to near-minimal long term resource
204   consumption.
205
206   If you are using this malloc in a long-lived program, it should
207   pay to experiment with these values.  As a rough guide, you
208   might set to a value close to the average size of a process
209   (program) running on your system.  Releasing this much memory
210   would allow such a process to run in memory.  Generally, it's
211   worth it to tune for trimming rather tham memory mapping when a
212   program undergoes phases where several large chunks are
213   allocated and released in ways that can reuse each other's
214   storage, perhaps mixed with phases where there are no such
215   chunks at all.  And in well-behaved long-lived programs,
216   controlling release of large blocks via trimming versus mapping
217   is usually faster.
218
219   However, in most programs, these parameters serve mainly as
220   protection against the system-level effects of carrying around
221   massive amounts of unneeded memory. Since frequent calls to
222   sbrk, mmap, and munmap otherwise degrade performance, the default
223   parameters are set to relatively high values that serve only as
224   safeguards.
225
226   The trim value must be greater than page size to have any useful
227   effect.  To disable trimming completely, you can set to
228   (unsigned long)(-1)
229
230   Trim settings interact with fastbin (MXFAST) settings: Unless
231   TRIM_FASTBINS is defined, automatic trimming never takes place upon
232   freeing a chunk with size less than or equal to MXFAST. Trimming is
233   instead delayed until subsequent freeing of larger chunks. However,
234   you can still force an attempted trim by calling malloc_trim.
235
236   Also, trimming is not generally possible in cases where
237   the main arena is obtained via mmap.
238
239   Note that the trick some people use of mallocing a huge space and
240   then freeing it at program startup, in an attempt to reserve system
241   memory, doesn't have the intended effect under automatic trimming,
242   since that memory will immediately be returned to the system.
243 */
244 #define M_TRIM_THRESHOLD       -1
245
246 #ifndef DEFAULT_TRIM_THRESHOLD
247 #define DEFAULT_TRIM_THRESHOLD (256 * 1024)
248 #endif
249
250 /*
251   M_TOP_PAD is the amount of extra `padding' space to allocate or
252   retain whenever sbrk is called. It is used in two ways internally:
253
254   * When sbrk is called to extend the top of the arena to satisfy
255   a new malloc request, this much padding is added to the sbrk
256   request.
257
258   * When malloc_trim is called automatically from free(),
259   it is used as the `pad' argument.
260
261   In both cases, the actual amount of padding is rounded
262   so that the end of the arena is always a system page boundary.
263
264   The main reason for using padding is to avoid calling sbrk so
265   often. Having even a small pad greatly reduces the likelihood
266   that nearly every malloc request during program start-up (or
267   after trimming) will invoke sbrk, which needlessly wastes
268   time.
269
270   Automatic rounding-up to page-size units is normally sufficient
271   to avoid measurable overhead, so the default is 0.  However, in
272   systems where sbrk is relatively slow, it can pay to increase
273   this value, at the expense of carrying around more memory than
274   the program needs.
275 */
276 #define M_TOP_PAD              -2
277
278 #ifndef DEFAULT_TOP_PAD
279 #define DEFAULT_TOP_PAD        (0)
280 #endif
281
282 /*
283   M_MMAP_THRESHOLD is the request size threshold for using mmap()
284   to service a request. Requests of at least this size that cannot
285   be allocated using already-existing space will be serviced via mmap.
286   (If enough normal freed space already exists it is used instead.)
287
288   Using mmap segregates relatively large chunks of memory so that
289   they can be individually obtained and released from the host
290   system. A request serviced through mmap is never reused by any
291   other request (at least not directly; the system may just so
292   happen to remap successive requests to the same locations).
293
294   Segregating space in this way has the benefits that:
295
296    1. Mmapped space can ALWAYS be individually released back
297       to the system, which helps keep the system level memory
298       demands of a long-lived program low.
299    2. Mapped memory can never become `locked' between
300       other chunks, as can happen with normally allocated chunks, which
301       means that even trimming via malloc_trim would not release them.
302    3. On some systems with "holes" in address spaces, mmap can obtain
303       memory that sbrk cannot.
304
305   However, it has the disadvantages that:
306
307    1. The space cannot be reclaimed, consolidated, and then
308       used to service later requests, as happens with normal chunks.
309    2. It can lead to more wastage because of mmap page alignment
310       requirements
311    3. It causes malloc performance to be more dependent on host
312       system memory management support routines which may vary in
313       implementation quality and may impose arbitrary
314       limitations. Generally, servicing a request via normal
315       malloc steps is faster than going through a system's mmap.
316
317   The advantages of mmap nearly always outweigh disadvantages for
318   "large" chunks, but the value of "large" varies across systems.  The
319   default is an empirically derived value that works well in most
320   systems.
321 */
322 #define M_MMAP_THRESHOLD      -3
323
324 #ifndef DEFAULT_MMAP_THRESHOLD
325 #define DEFAULT_MMAP_THRESHOLD (256 * 1024)
326 #endif
327
328 /*
329   M_MMAP_MAX is the maximum number of requests to simultaneously
330   service using mmap. This parameter exists because
331 . Some systems have a limited number of internal tables for
332   use by mmap, and using more than a few of them may degrade
333   performance.
334
335   The default is set to a value that serves only as a safeguard.
336   Setting to 0 disables use of mmap for servicing large requests.  If
337   HAVE_MMAP is not set, the default value is 0, and attempts to set it
338   to non-zero values in mallopt will fail.
339 */
340 #define M_MMAP_MAX             -4
341
342 #ifndef DEFAULT_MMAP_MAX
343 #define DEFAULT_MMAP_MAX       (65536)
344 #endif
345
346
347 /* ------------------ MMAP support ------------------  */
348 #include <fcntl.h>
349 #include <sys/mman.h>
350
351 #if !defined(MAP_ANONYMOUS) && defined(MAP_ANON)
352 #define MAP_ANONYMOUS MAP_ANON
353 #endif
354
355 #ifdef __ARCH_USE_MMU__
356
357 #define MMAP(addr, size, prot) \
358  (mmap((addr), (size), (prot), MAP_PRIVATE|MAP_ANONYMOUS, 0, 0))
359
360 #else
361
362 #define MMAP(addr, size, prot) \
363  (mmap((addr), (size), (prot), MAP_SHARED|MAP_ANONYMOUS, 0, 0))
364
365 #endif
366
367
368 /* -----------------------  Chunk representations ----------------------- */
369
370
371 /*
372   This struct declaration is misleading (but accurate and necessary).
373   It declares a "view" into memory allowing access to necessary
374   fields at known offsets from a given base. See explanation below.
375 */
376
377 struct malloc_chunk {
378
379   size_t      prev_size;  /* Size of previous chunk (if free).  */
380   size_t      size;       /* Size in bytes, including overhead. */
381
382   struct malloc_chunk* fd;         /* double links -- used only if free. */
383   struct malloc_chunk* bk;
384 };
385
386
387 typedef struct malloc_chunk* mchunkptr;
388
389 /*
390    malloc_chunk details:
391
392     (The following includes lightly edited explanations by Colin Plumb.)
393
394     Chunks of memory are maintained using a `boundary tag' method as
395     described in e.g., Knuth or Standish.  (See the paper by Paul
396     Wilson ftp://ftp.cs.utexas.edu/pub/garbage/allocsrv.ps for a
397     survey of such techniques.)  Sizes of free chunks are stored both
398     in the front of each chunk and at the end.  This makes
399     consolidating fragmented chunks into bigger chunks very fast.  The
400     size fields also hold bits representing whether chunks are free or
401     in use.
402
403     An allocated chunk looks like this:
404
405
406     chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
407             |             Size of previous chunk, if allocated            | |
408             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
409             |             Size of chunk, in bytes                         |P|
410       mem-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
411             |             User data starts here...                          .
412             .                                                               .
413             .             (malloc_usable_space() bytes)                     .
414             .                                                               |
415 nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
416             |             Size of chunk                                     |
417             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
418
419
420     Where "chunk" is the front of the chunk for the purpose of most of
421     the malloc code, but "mem" is the pointer that is returned to the
422     user.  "Nextchunk" is the beginning of the next contiguous chunk.
423
424     Chunks always begin on even word boundries, so the mem portion
425     (which is returned to the user) is also on an even word boundary, and
426     thus at least double-word aligned.
427
428     Free chunks are stored in circular doubly-linked lists, and look like this:
429
430     chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
431             |             Size of previous chunk                            |
432             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
433     `head:' |             Size of chunk, in bytes                         |P|
434       mem-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
435             |             Forward pointer to next chunk in list             |
436             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
437             |             Back pointer to previous chunk in list            |
438             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
439             |             Unused space (may be 0 bytes long)                .
440             .                                                               .
441             .                                                               |
442 nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
443     `foot:' |             Size of chunk, in bytes                           |
444             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
445
446     The P (PREV_INUSE) bit, stored in the unused low-order bit of the
447     chunk size (which is always a multiple of two words), is an in-use
448     bit for the *previous* chunk.  If that bit is *clear*, then the
449     word before the current chunk size contains the previous chunk
450     size, and can be used to find the front of the previous chunk.
451     The very first chunk allocated always has this bit set,
452     preventing access to non-existent (or non-owned) memory. If
453     prev_inuse is set for any given chunk, then you CANNOT determine
454     the size of the previous chunk, and might even get a memory
455     addressing fault when trying to do so.
456
457     Note that the `foot' of the current chunk is actually represented
458     as the prev_size of the NEXT chunk. This makes it easier to
459     deal with alignments etc but can be very confusing when trying
460     to extend or adapt this code.
461
462     The two exceptions to all this are
463
464      1. The special chunk `top' doesn't bother using the
465         trailing size field since there is no next contiguous chunk
466         that would have to index off it. After initialization, `top'
467         is forced to always exist.  If it would become less than
468         MINSIZE bytes long, it is replenished.
469
470      2. Chunks allocated via mmap, which have the second-lowest-order
471         bit (IS_MMAPPED) set in their size fields.  Because they are
472         allocated one-by-one, each must contain its own trailing size field.
473
474 */
475
476 /*
477   ---------- Size and alignment checks and conversions ----------
478 */
479
480 /* conversion from malloc headers to user pointers, and back */
481
482 #define chunk2mem(p)   ((void*)((char*)(p) + 2*(sizeof(size_t))))
483 #define mem2chunk(mem) ((mchunkptr)((char*)(mem) - 2*(sizeof(size_t))))
484
485 /* The smallest possible chunk */
486 #define MIN_CHUNK_SIZE        (sizeof(struct malloc_chunk))
487
488 /* The smallest size we can malloc is an aligned minimal chunk */
489
490 #define MINSIZE  \
491   (unsigned long)(((MIN_CHUNK_SIZE+MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK))
492
493 /* Check if m has acceptable alignment */
494
495 #define aligned_OK(m)  (((unsigned long)((m)) & (MALLOC_ALIGN_MASK)) == 0)
496
497
498 /* Check if a request is so large that it would wrap around zero when
499    padded and aligned. To simplify some other code, the bound is made
500    low enough so that adding MINSIZE will also not wrap around sero.
501 */
502
503 #define REQUEST_OUT_OF_RANGE(req)                                 \
504   ((unsigned long)(req) >=                                        \
505    (unsigned long)(size_t)(-2 * MINSIZE))
506
507 /* pad request bytes into a usable size -- internal version */
508
509 #define request2size(req)                                         \
510   (((req) + (sizeof(size_t)) + MALLOC_ALIGN_MASK < MINSIZE)  ?             \
511    MINSIZE :                                                      \
512    ((req) + (sizeof(size_t)) + MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK)
513
514 /*  Same, except also perform argument check */
515
516 #define checked_request2size(req, sz)                             \
517   if (REQUEST_OUT_OF_RANGE(req)) {                                \
518     errno = ENOMEM;                                               \
519     return 0;                                                     \
520   }                                                               \
521   (sz) = request2size(req);
522
523 /*
524   --------------- Physical chunk operations ---------------
525 */
526
527
528 /* size field is or'ed with PREV_INUSE when previous adjacent chunk in use */
529 #define PREV_INUSE 0x1
530
531 /* extract inuse bit of previous chunk */
532 #define prev_inuse(p)       ((p)->size & PREV_INUSE)
533
534
535 /* size field is or'ed with IS_MMAPPED if the chunk was obtained with mmap() */
536 #define IS_MMAPPED 0x2
537
538 /* check for mmap()'ed chunk */
539 #define chunk_is_mmapped(p) ((p)->size & IS_MMAPPED)
540
541 /* Bits to mask off when extracting size
542
543   Note: IS_MMAPPED is intentionally not masked off from size field in
544   macros for which mmapped chunks should never be seen. This should
545   cause helpful core dumps to occur if it is tried by accident by
546   people extending or adapting this malloc.
547 */
548 #define SIZE_BITS (PREV_INUSE|IS_MMAPPED)
549
550 /* Get size, ignoring use bits */
551 #define chunksize(p)         ((p)->size & ~(SIZE_BITS))
552
553
554 /* Ptr to next physical malloc_chunk. */
555 #define next_chunk(p) ((mchunkptr)( ((char*)(p)) + ((p)->size & ~PREV_INUSE) ))
556
557 /* Ptr to previous physical malloc_chunk */
558 #define prev_chunk(p) ((mchunkptr)( ((char*)(p)) - ((p)->prev_size) ))
559
560 /* Treat space at ptr + offset as a chunk */
561 #define chunk_at_offset(p, s)  ((mchunkptr)(((char*)(p)) + (s)))
562
563 /* extract p's inuse bit */
564 #define inuse(p)\
565 ((((mchunkptr)(((char*)(p))+((p)->size & ~PREV_INUSE)))->size) & PREV_INUSE)
566
567 /* set/clear chunk as being inuse without otherwise disturbing */
568 #define set_inuse(p)\
569 ((mchunkptr)(((char*)(p)) + ((p)->size & ~PREV_INUSE)))->size |= PREV_INUSE
570
571 #define clear_inuse(p)\
572 ((mchunkptr)(((char*)(p)) + ((p)->size & ~PREV_INUSE)))->size &= ~(PREV_INUSE)
573
574
575 /* check/set/clear inuse bits in known places */
576 #define inuse_bit_at_offset(p, s)\
577  (((mchunkptr)(((char*)(p)) + (s)))->size & PREV_INUSE)
578
579 #define set_inuse_bit_at_offset(p, s)\
580  (((mchunkptr)(((char*)(p)) + (s)))->size |= PREV_INUSE)
581
582 #define clear_inuse_bit_at_offset(p, s)\
583  (((mchunkptr)(((char*)(p)) + (s)))->size &= ~(PREV_INUSE))
584
585
586 /* Set size at head, without disturbing its use bit */
587 #define set_head_size(p, s)  ((p)->size = (((p)->size & PREV_INUSE) | (s)))
588
589 /* Set size/use field */
590 #define set_head(p, s)       ((p)->size = (s))
591
592 /* Set size at footer (only when chunk is not in use) */
593 #define set_foot(p, s)       (((mchunkptr)((char*)(p) + (s)))->prev_size = (s))
594
595
596 /* -------------------- Internal data structures -------------------- */
597
598 /*
599   Bins
600
601     An array of bin headers for free chunks. Each bin is doubly
602     linked.  The bins are approximately proportionally (log) spaced.
603     There are a lot of these bins (128). This may look excessive, but
604     works very well in practice.  Most bins hold sizes that are
605     unusual as malloc request sizes, but are more usual for fragments
606     and consolidated sets of chunks, which is what these bins hold, so
607     they can be found quickly.  All procedures maintain the invariant
608     that no consolidated chunk physically borders another one, so each
609     chunk in a list is known to be preceeded and followed by either
610     inuse chunks or the ends of memory.
611
612     Chunks in bins are kept in size order, with ties going to the
613     approximately least recently used chunk. Ordering isn't needed
614     for the small bins, which all contain the same-sized chunks, but
615     facilitates best-fit allocation for larger chunks. These lists
616     are just sequential. Keeping them in order almost never requires
617     enough traversal to warrant using fancier ordered data
618     structures.
619
620     Chunks of the same size are linked with the most
621     recently freed at the front, and allocations are taken from the
622     back.  This results in LRU (FIFO) allocation order, which tends
623     to give each chunk an equal opportunity to be consolidated with
624     adjacent freed chunks, resulting in larger free chunks and less
625     fragmentation.
626
627     To simplify use in double-linked lists, each bin header acts
628     as a malloc_chunk. This avoids special-casing for headers.
629     But to conserve space and improve locality, we allocate
630     only the fd/bk pointers of bins, and then use repositioning tricks
631     to treat these as the fields of a malloc_chunk*.
632 */
633
634 typedef struct malloc_chunk* mbinptr;
635
636 /* addressing -- note that bin_at(0) does not exist */
637 #define bin_at(m, i) ((mbinptr)((char*)&((m)->bins[(i)<<1]) - ((sizeof(size_t))<<1)))
638
639 /* analog of ++bin */
640 #define next_bin(b)  ((mbinptr)((char*)(b) + (sizeof(mchunkptr)<<1)))
641
642 /* Reminders about list directionality within bins */
643 #define first(b)     ((b)->fd)
644 #define last(b)      ((b)->bk)
645
646 /* Take a chunk off a bin list */
647 #define unlink(P, BK, FD) {                                            \
648   FD = P->fd;                                                          \
649   BK = P->bk;                                                          \
650   if (FD->bk != P || BK->fd != P)                                      \
651       abort();                                                         \
652   FD->bk = BK;                                                         \
653   BK->fd = FD;                                                         \
654 }
655
656 /*
657   Indexing
658
659     Bins for sizes < 512 bytes contain chunks of all the same size, spaced
660     8 bytes apart. Larger bins are approximately logarithmically spaced:
661
662     64 bins of size       8
663     32 bins of size      64
664     16 bins of size     512
665      8 bins of size    4096
666      4 bins of size   32768
667      2 bins of size  262144
668      1 bin  of size what's left
669
670     The bins top out around 1MB because we expect to service large
671     requests via mmap.
672 */
673
674 #define NBINS              96
675 #define NSMALLBINS         32
676 #define SMALLBIN_WIDTH      8
677 #define MIN_LARGE_SIZE    256
678
679 #define in_smallbin_range(sz)  \
680   ((unsigned long)(sz) < (unsigned long)MIN_LARGE_SIZE)
681
682 #define smallbin_index(sz)     (((unsigned)(sz)) >> 3)
683
684 #define bin_index(sz) \
685  ((in_smallbin_range(sz)) ? smallbin_index(sz) : __malloc_largebin_index(sz))
686
687 /*
688   FIRST_SORTED_BIN_SIZE is the chunk size corresponding to the
689   first bin that is maintained in sorted order. This must
690   be the smallest size corresponding to a given bin.
691
692   Normally, this should be MIN_LARGE_SIZE. But you can weaken
693   best fit guarantees to sometimes speed up malloc by increasing value.
694   Doing this means that malloc may choose a chunk that is
695   non-best-fitting by up to the width of the bin.
696
697   Some useful cutoff values:
698       512 - all bins sorted
699      2560 - leaves bins <=     64 bytes wide unsorted
700     12288 - leaves bins <=    512 bytes wide unsorted
701     65536 - leaves bins <=   4096 bytes wide unsorted
702    262144 - leaves bins <=  32768 bytes wide unsorted
703        -1 - no bins sorted (not recommended!)
704 */
705
706 #define FIRST_SORTED_BIN_SIZE MIN_LARGE_SIZE
707 /* #define FIRST_SORTED_BIN_SIZE 65536 */
708
709 /*
710   Unsorted chunks
711
712     All remainders from chunk splits, as well as all returned chunks,
713     are first placed in the "unsorted" bin. They are then placed
714     in regular bins after malloc gives them ONE chance to be used before
715     binning. So, basically, the unsorted_chunks list acts as a queue,
716     with chunks being placed on it in free (and __malloc_consolidate),
717     and taken off (to be either used or placed in bins) in malloc.
718 */
719
720 /* The otherwise unindexable 1-bin is used to hold unsorted chunks. */
721 #define unsorted_chunks(M)          (bin_at(M, 1))
722
723 /*
724   Top
725
726     The top-most available chunk (i.e., the one bordering the end of
727     available memory) is treated specially. It is never included in
728     any bin, is used only if no other chunk is available, and is
729     released back to the system if it is very large (see
730     M_TRIM_THRESHOLD).  Because top initially
731     points to its own bin with initial zero size, thus forcing
732     extension on the first malloc request, we avoid having any special
733     code in malloc to check whether it even exists yet. But we still
734     need to do so when getting memory from system, so we make
735     initial_top treat the bin as a legal but unusable chunk during the
736     interval between initialization and the first call to
737     __malloc_alloc. (This is somewhat delicate, since it relies on
738     the 2 preceding words to be zero during this interval as well.)
739 */
740
741 /* Conveniently, the unsorted bin can be used as dummy top on first call */
742 #define initial_top(M)              (unsorted_chunks(M))
743
744 /*
745   Binmap
746
747     To help compensate for the large number of bins, a one-level index
748     structure is used for bin-by-bin searching.  `binmap' is a
749     bitvector recording whether bins are definitely empty so they can
750     be skipped over during during traversals.  The bits are NOT always
751     cleared as soon as bins are empty, but instead only
752     when they are noticed to be empty during traversal in malloc.
753 */
754
755 /* Conservatively use 32 bits per map word, even if on 64bit system */
756 #define BINMAPSHIFT      5
757 #define BITSPERMAP       (1U << BINMAPSHIFT)
758 #define BINMAPSIZE       (NBINS / BITSPERMAP)
759
760 #define idx2block(i)     ((i) >> BINMAPSHIFT)
761 #define idx2bit(i)       ((1U << ((i) & ((1U << BINMAPSHIFT)-1))))
762
763 #define mark_bin(m,i)    ((m)->binmap[idx2block(i)] |=  idx2bit(i))
764 #define unmark_bin(m,i)  ((m)->binmap[idx2block(i)] &= ~(idx2bit(i)))
765 #define get_binmap(m,i)  ((m)->binmap[idx2block(i)] &   idx2bit(i))
766
767 /*
768   Fastbins
769
770     An array of lists holding recently freed small chunks.  Fastbins
771     are not doubly linked.  It is faster to single-link them, and
772     since chunks are never removed from the middles of these lists,
773     double linking is not necessary. Also, unlike regular bins, they
774     are not even processed in FIFO order (they use faster LIFO) since
775     ordering doesn't much matter in the transient contexts in which
776     fastbins are normally used.
777
778     Chunks in fastbins keep their inuse bit set, so they cannot
779     be consolidated with other free chunks. __malloc_consolidate
780     releases all chunks in fastbins and consolidates them with
781     other free chunks.
782 */
783
784 typedef struct malloc_chunk* mfastbinptr;
785
786 /* offset 2 to use otherwise unindexable first 2 bins */
787 #define fastbin_index(sz)        ((((unsigned int)(sz)) >> 3) - 2)
788
789 /* The maximum fastbin request size we support */
790 #define MAX_FAST_SIZE     80
791
792 #define NFASTBINS  (fastbin_index(request2size(MAX_FAST_SIZE))+1)
793
794 /*
795   FASTBIN_CONSOLIDATION_THRESHOLD is the size of a chunk in free()
796   that triggers automatic consolidation of possibly-surrounding
797   fastbin chunks. This is a heuristic, so the exact value should not
798   matter too much. It is defined at half the default trim threshold as a
799   compromise heuristic to only attempt consolidation if it is likely
800   to lead to trimming. However, it is not dynamically tunable, since
801   consolidation reduces fragmentation surrounding loarge chunks even
802   if trimming is not used.
803 */
804
805 #define FASTBIN_CONSOLIDATION_THRESHOLD  \
806   ((unsigned long)(DEFAULT_TRIM_THRESHOLD) >> 1)
807
808 /*
809   Since the lowest 2 bits in max_fast don't matter in size comparisons,
810   they are used as flags.
811 */
812
813 /*
814   ANYCHUNKS_BIT held in max_fast indicates that there may be any
815   freed chunks at all. It is set true when entering a chunk into any
816   bin.
817 */
818
819 #define ANYCHUNKS_BIT        (1U)
820
821 #define have_anychunks(M)     (((M)->max_fast &  ANYCHUNKS_BIT))
822 #define set_anychunks(M)      ((M)->max_fast |=  ANYCHUNKS_BIT)
823 #define clear_anychunks(M)    ((M)->max_fast &= ~ANYCHUNKS_BIT)
824
825 /*
826   FASTCHUNKS_BIT held in max_fast indicates that there are probably
827   some fastbin chunks. It is set true on entering a chunk into any
828   fastbin, and cleared only in __malloc_consolidate.
829 */
830
831 #define FASTCHUNKS_BIT        (2U)
832
833 #define have_fastchunks(M)   (((M)->max_fast &  FASTCHUNKS_BIT))
834 #define set_fastchunks(M)    ((M)->max_fast |=  (FASTCHUNKS_BIT|ANYCHUNKS_BIT))
835 #define clear_fastchunks(M)  ((M)->max_fast &= ~(FASTCHUNKS_BIT))
836
837 /* Set value of max_fast.  Use impossibly small value if 0.  */
838 #define set_max_fast(M, s) \
839   (M)->max_fast = (((s) == 0)? SMALLBIN_WIDTH: request2size(s)) | \
840   ((M)->max_fast &  (FASTCHUNKS_BIT|ANYCHUNKS_BIT))
841
842 #define get_max_fast(M) \
843   ((M)->max_fast & ~(FASTCHUNKS_BIT | ANYCHUNKS_BIT))
844
845
846 /*
847   morecore_properties is a status word holding dynamically discovered
848   or controlled properties of the morecore function
849 */
850
851 #define MORECORE_CONTIGUOUS_BIT  (1U)
852
853 #define contiguous(M) \
854         (((M)->morecore_properties &  MORECORE_CONTIGUOUS_BIT))
855 #define noncontiguous(M) \
856         (((M)->morecore_properties &  MORECORE_CONTIGUOUS_BIT) == 0)
857 #define set_contiguous(M) \
858         ((M)->morecore_properties |=  MORECORE_CONTIGUOUS_BIT)
859 #define set_noncontiguous(M) \
860         ((M)->morecore_properties &= ~MORECORE_CONTIGUOUS_BIT)
861
862
863 /*
864    ----------- Internal state representation and initialization -----------
865 */
866
867 struct malloc_state {
868
869   /* The maximum chunk size to be eligible for fastbin */
870   size_t  max_fast;   /* low 2 bits used as flags */
871
872   /* Fastbins */
873   mfastbinptr      fastbins[NFASTBINS];
874
875   /* Base of the topmost chunk -- not otherwise kept in a bin */
876   mchunkptr        top;
877
878   /* The remainder from the most recent split of a small request */
879   mchunkptr        last_remainder;
880
881   /* Normal bins packed as described above */
882   mchunkptr        bins[NBINS * 2];
883
884   /* Bitmap of bins. Trailing zero map handles cases of largest binned size */
885   unsigned int     binmap[BINMAPSIZE+1];
886
887   /* Tunable parameters */
888   unsigned long     trim_threshold;
889   size_t  top_pad;
890   size_t  mmap_threshold;
891
892   /* Memory map support */
893   int              n_mmaps;
894   int              n_mmaps_max;
895   int              max_n_mmaps;
896
897   /* Cache malloc_getpagesize */
898   unsigned int     pagesize;
899
900   /* Track properties of MORECORE */
901   unsigned int     morecore_properties;
902
903   /* Statistics */
904   size_t  mmapped_mem;
905   size_t  sbrked_mem;
906   size_t  max_sbrked_mem;
907   size_t  max_mmapped_mem;
908   size_t  max_total_mem;
909 };
910
911 typedef struct malloc_state *mstate;
912
913 /*
914    There is exactly one instance of this struct in this malloc.
915    If you are adapting this malloc in a way that does NOT use a static
916    malloc_state, you MUST explicitly zero-fill it before using. This
917    malloc relies on the property that malloc_state is initialized to
918    all zeroes (as is true of C statics).
919 */
920 extern struct malloc_state __malloc_state;  /* never directly referenced */
921
922 /*
923    All uses of av_ are via get_malloc_state().
924    At most one "call" to get_malloc_state is made per invocation of
925    the public versions of malloc and free, but other routines
926    that in turn invoke malloc and/or free may call more then once.
927    Also, it is called in check* routines if __UCLIBC_MALLOC_DEBUGGING__ is set.
928 */
929
930 #define get_malloc_state() (&(__malloc_state))
931
932 /* External internal utilities operating on mstates */
933 void   __malloc_consolidate(mstate) attribute_hidden;
934
935
936 /* Debugging support */
937 #ifndef __UCLIBC_MALLOC_DEBUGGING__
938
939 #define check_chunk(P)
940 #define check_free_chunk(P)
941 #define check_inuse_chunk(P)
942 #define check_remalloced_chunk(P,N)
943 #define check_malloced_chunk(P,N)
944 #define check_malloc_state()
945 #define assert(x) ((void)0)
946
947
948 #else
949
950 #define check_chunk(P)              __do_check_chunk(P)
951 #define check_free_chunk(P)         __do_check_free_chunk(P)
952 #define check_inuse_chunk(P)        __do_check_inuse_chunk(P)
953 #define check_remalloced_chunk(P,N) __do_check_remalloced_chunk(P,N)
954 #define check_malloced_chunk(P,N)   __do_check_malloced_chunk(P,N)
955 #define check_malloc_state()        __do_check_malloc_state()
956
957 extern void __do_check_chunk(mchunkptr p);
958 extern void __do_check_free_chunk(mchunkptr p);
959 extern void __do_check_inuse_chunk(mchunkptr p);
960 extern void __do_check_remalloced_chunk(mchunkptr p, size_t s);
961 extern void __do_check_malloced_chunk(mchunkptr p, size_t s);
962 extern void __do_check_malloc_state(void);
963
964 #include <assert.h>
965
966 #endif