aboutsummaryrefslogtreecommitdiff
path: root/malloc/malloc.c
diff options
context:
space:
mode:
Diffstat (limited to 'malloc/malloc.c')
-rw-r--r--malloc/malloc.c8004
1 files changed, 4127 insertions, 3877 deletions
diff --git a/malloc/malloc.c b/malloc/malloc.c
index 8279ddaf22..e663f84707 100644
--- a/malloc/malloc.c
+++ b/malloc/malloc.c
@@ -1,32 +1,47 @@
/* Malloc implementation for multiple threads without lock contention.
Copyright (C) 1996,1997,1998,1999,2000,2001 Free Software Foundation, Inc.
This file is part of the GNU C Library.
- Contributed by Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
- and Doug Lea <dl@cs.oswego.edu>, 1996.
+ Contributed by Wolfram Gloger <wg@malloc.de>
+ and Doug Lea <dl@cs.oswego.edu>, 2001.
The GNU C Library is free software; you can redistribute it and/or
- modify it under the terms of the GNU Lesser General Public
- License as published by the Free Software Foundation; either
- version 2.1 of the License, or (at your option) any later version.
+ modify it under the terms of the GNU Library General Public License as
+ published by the Free Software Foundation; either version 2 of the
+ License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
+ Library General Public License for more details.
- You should have received a copy of the GNU Lesser General Public
- License along with the GNU C Library; if not, write to the Free
- Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
- 02111-1307 USA. */
+ You should have received a copy of the GNU Library General Public
+ License along with the GNU C Library; see the file COPYING.LIB. If not,
+ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA. */
-/* $Id$
+/*
+ This is a version (aka ptmalloc2) of malloc/free/realloc written by
+ Doug Lea and adapted to multiple threads/arenas by Wolfram Gloger.
+
+* Version ptmalloc2-20011215
+ $Id$
+ based on:
+ VERSION 2.7.0 Sun Mar 11 14:14:06 2001 Doug Lea (dl at gee)
- This work is mainly derived from malloc-2.6.4 by Doug Lea
- <dl@cs.oswego.edu>, which is available from:
+ Note: There may be an updated version of this malloc obtainable at
+ http://www.malloc.de/malloc/ptmalloc2.tar.gz
+ Check before installing!
- ftp://g.oswego.edu/pub/misc/malloc.c
+* Quickstart
- Most of the original comments are reproduced in the code below.
+ In order to compile this implementation, a Makefile is provided with
+ the ptmalloc2 distribution, which has pre-defined targets for some
+ popular systems (e.g. "make posix" for Posix threads). All that is
+ typically required with regard to compiler flags is the selection of
+ the thread package via defining one out of USE_PTHREADS, USE_THR or
+ USE_SPROC. Check the thread-m.h file for what effects this has.
+ Many/most systems will additionally require USE_TSD_DATA_HACK to be
+ defined, so this is the default for "make posix".
* Why use this malloc?
@@ -34,85 +49,62 @@
most tunable malloc ever written. However it is among the fastest
while also being among the most space-conserving, portable and tunable.
Consistent balance across these factors results in a good general-purpose
- allocator. For a high-level description, see
- http://g.oswego.edu/dl/html/malloc.html
-
- On many systems, the standard malloc implementation is by itself not
- thread-safe, and therefore wrapped with a single global lock around
- all malloc-related functions. In some applications, especially with
- multiple available processors, this can lead to contention problems
- and bad performance. This malloc version was designed with the goal
- to avoid waiting for locks as much as possible. Statistics indicate
- that this goal is achieved in many cases.
-
-* Synopsis of public routines
-
- (Much fuller descriptions are contained in the program documentation below.)
-
- ptmalloc_init();
- Initialize global configuration. When compiled for multiple threads,
- this function must be called once before any other function in the
- package. It is not required otherwise. It is called automatically
- in the Linux/GNU C libray or when compiling with MALLOC_HOOKS.
- malloc(size_t n);
- Return a pointer to a newly allocated chunk of at least n bytes, or null
- if no space is available.
- free(Void_t* p);
- Release the chunk of memory pointed to by p, or no effect if p is null.
- realloc(Void_t* p, size_t n);
- Return a pointer to a chunk of size n that contains the same data
- as does chunk p up to the minimum of (n, p's size) bytes, or null
- if no space is available. The returned pointer may or may not be
- the same as p. If p is null, equivalent to malloc. Unless the
- #define REALLOC_ZERO_BYTES_FREES below is set, realloc with a
- size argument of zero (re)allocates a minimum-sized chunk.
- memalign(size_t alignment, size_t n);
- Return a pointer to a newly allocated chunk of n bytes, aligned
- in accord with the alignment argument, which must be a power of
- two.
- valloc(size_t n);
- Equivalent to memalign(pagesize, n), where pagesize is the page
- size of the system (or as near to this as can be figured out from
- all the includes/defines below.)
- pvalloc(size_t n);
- Equivalent to valloc(minimum-page-that-holds(n)), that is,
- round up n to nearest pagesize.
- calloc(size_t unit, size_t quantity);
- Returns a pointer to quantity * unit bytes, with all locations
- set to zero.
- cfree(Void_t* p);
- Equivalent to free(p).
- malloc_trim(size_t pad);
- Release all but pad bytes of freed top-most memory back
- to the system. Return 1 if successful, else 0.
- malloc_usable_size(Void_t* p);
- Report the number usable allocated bytes associated with allocated
- chunk p. This may or may not report more bytes than were requested,
- due to alignment and minimum size constraints.
- malloc_stats();
- Prints brief summary statistics on stderr.
- mallinfo()
- Returns (by copy) a struct containing various summary statistics.
- mallopt(int parameter_number, int parameter_value)
- Changes one of the tunable parameters described below. Returns
- 1 if successful in changing the parameter, else 0.
+ allocator for malloc-intensive programs.
+
+ The main properties of the algorithms are:
+ * For large (>= 512 bytes) requests, it is a pure best-fit allocator,
+ with ties normally decided via FIFO (i.e. least recently used).
+ * For small (<= 64 bytes by default) requests, it is a caching
+ allocator, that maintains pools of quickly recycled chunks.
+ * In between, and for combinations of large and small requests, it does
+ the best it can trying to meet both goals at once.
+ * For very large requests (>= 128KB by default), it relies on system
+ memory mapping facilities, if supported.
+
+ For a longer but slightly out of date high-level description, see
+ http://gee.cs.oswego.edu/dl/html/malloc.html
+
+ You may already by default be using a C library containing a malloc
+ that is based on some version of this malloc (for example in
+ linux). You might still want to use the one in this file in order to
+ customize settings or to avoid overheads associated with library
+ versions.
+
+* Contents, described in more detail in "description of public routines" below.
+
+ Standard (ANSI/SVID/...) functions:
+ malloc(size_t n);
+ calloc(size_t n_elements, size_t element_size);
+ free(Void_t* p);
+ realloc(Void_t* p, size_t n);
+ memalign(size_t alignment, size_t n);
+ valloc(size_t n);
+ mallinfo()
+ mallopt(int parameter_number, int parameter_value)
+
+ Additional functions:
+ independent_calloc(size_t n_elements, size_t size, Void_t* chunks[]);
+ independent_comalloc(size_t n_elements, size_t sizes[], Void_t* chunks[]);
+ pvalloc(size_t n);
+ cfree(Void_t* p);
+ malloc_trim(size_t pad);
+ malloc_usable_size(Void_t* p);
+ malloc_stats();
* Vital statistics:
- Alignment: 8-byte
- 8 byte alignment is currently hardwired into the design. This
- seems to suffice for all current machines and C compilers.
-
- Assumed pointer representation: 4 or 8 bytes
- Code for 8-byte pointers is untested by me but has worked
- reliably by Wolfram Gloger, who contributed most of the
- changes supporting this.
-
- Assumed size_t representation: 4 or 8 bytes
+ Supported pointer representation: 4 or 8 bytes
+ Supported size_t representation: 4 or 8 bytes
Note that size_t is allowed to be 4 bytes even if pointers are 8.
+ You can adjust this by defining INTERNAL_SIZE_T
- Minimum overhead per allocated chunk: 4 or 8 bytes
- Each malloced chunk has a hidden overhead of 4 bytes holding size
+ Alignment: 2 * sizeof(size_t) (default)
+ (i.e., 8 byte alignment with 4byte size_t). This suffices for
+ nearly all current machines and C compilers. However, you can
+ define MALLOC_ALIGNMENT to be wider than this if necessary.
+
+ Minimum overhead per allocated chunk: 4 or 8 bytes
+ Each malloced chunk has a hidden word of overhead holding size
and status information.
Minimum allocated size: 4-byte ptrs: 16 bytes (including 4 overhead)
@@ -120,182 +112,136 @@
When a chunk is freed, 12 (for 4byte ptrs) or 20 (for 8 byte
ptrs but 4 byte size) or 24 (for 8/8) additional bytes are
- needed; 4 (8) for a trailing size field
- and 8 (16) bytes for free list pointers. Thus, the minimum
- allocatable size is 16/24/32 bytes.
+ needed; 4 (8) for a trailing size field and 8 (16) bytes for
+ free list pointers. Thus, the minimum allocatable size is
+ 16/24/32 bytes.
Even a request for zero bytes (i.e., malloc(0)) returns a
pointer to something of the minimum allocatable size.
- Maximum allocated size: 4-byte size_t: 2^31 - 8 bytes
- 8-byte size_t: 2^63 - 16 bytes
+ The maximum overhead wastage (i.e., number of extra bytes
+ allocated than were requested in malloc) is less than or equal
+ to the minimum size, except for requests >= mmap_threshold that
+ are serviced via mmap(), where the worst case wastage is 2 *
+ sizeof(size_t) bytes plus the remainder from a system page (the
+ minimal mmap unit); typically 4096 or 8192 bytes.
+
+ Maximum allocated size: 4-byte size_t: 2^32 minus about two pages
+ 8-byte size_t: 2^64 minus about two pages
- It is assumed that (possibly signed) size_t bit values suffice to
+ It is assumed that (possibly signed) size_t values suffice to
represent chunk sizes. `Possibly signed' is due to the fact
that `size_t' may be defined on a system as either a signed or
- an unsigned type. To be conservative, values that would appear
- as negative numbers are avoided.
- Requests for sizes with a negative sign bit will return a
- minimum-sized chunk.
-
- Maximum overhead wastage per allocated chunk: normally 15 bytes
-
- Alignment demands, plus the minimum allocatable size restriction
- make the normal worst-case wastage 15 bytes (i.e., up to 15
- more bytes will be allocated than were requested in malloc), with
- two exceptions:
- 1. Because requests for zero bytes allocate non-zero space,
- the worst case wastage for a request of zero bytes is 24 bytes.
- 2. For requests >= mmap_threshold that are serviced via
- mmap(), the worst case wastage is 8 bytes plus the remainder
- from a system page (the minimal mmap unit); typically 4096 bytes.
-
-* Limitations
-
- Here are some features that are NOT currently supported
-
- * No automated mechanism for fully checking that all accesses
- to malloced memory stay within their bounds.
- * No support for compaction.
+ an unsigned type. The ISO C standard says that it must be
+ unsigned, but a few systems are known not to adhere to this.
+ Additionally, even when size_t is unsigned, sbrk (which is by
+ default used to obtain memory from system) accepts signed
+ arguments, and may not be able to handle size_t-wide arguments
+ with negative sign bit. Generally, values that would
+ appear as negative after accounting for overhead and alignment
+ are supported only via mmap(), which does not have this
+ limitation.
+
+ Requests for sizes outside the allowed range will perform an optional
+ failure action and then return null. (Requests may also
+ also fail because a system is out of memory.)
+
+ Thread-safety: thread-safe unless NO_THREADS is defined
+
+ Compliance: I believe it is compliant with the 1997 Single Unix Specification
+ (See http://www.opennc.org). Also SVID/XPG, ANSI C, and probably
+ others as well.
* Synopsis of compile-time options:
People have reported using previous versions of this malloc on all
versions of Unix, sometimes by tweaking some of the defines
below. It has been tested most extensively on Solaris and
- Linux. People have also reported adapting this malloc for use in
- stand-alone embedded systems.
-
- The implementation is in straight, hand-tuned ANSI C. Among other
- consequences, it uses a lot of macros. Because of this, to be at
- all usable, this code should be compiled using an optimizing compiler
- (for example gcc -O2) that can simplify expressions and control
- paths.
-
- __STD_C (default: derived from C compiler defines)
- Nonzero if using ANSI-standard C compiler, a C++ compiler, or
- a C compiler sufficiently close to ANSI to get away with it.
- MALLOC_DEBUG (default: NOT defined)
- Define to enable debugging. Adds fairly extensive assertion-based
- checking to help track down memory errors, but noticeably slows down
- execution.
- MALLOC_HOOKS (default: NOT defined)
- Define to enable support run-time replacement of the allocation
- functions through user-defined `hooks'.
- REALLOC_ZERO_BYTES_FREES (default: defined)
- Define this if you think that realloc(p, 0) should be equivalent
- to free(p). (The C standard requires this behaviour, therefore
- it is the default.) Otherwise, since malloc returns a unique
- pointer for malloc(0), so does realloc(p, 0).
- HAVE_MEMCPY (default: defined)
- Define if you are not otherwise using ANSI STD C, but still
- have memcpy and memset in your C library and want to use them.
- Otherwise, simple internal versions are supplied.
- USE_MEMCPY (default: 1 if HAVE_MEMCPY is defined, 0 otherwise)
- Define as 1 if you want the C library versions of memset and
- memcpy called in realloc and calloc (otherwise macro versions are used).
- At least on some platforms, the simple macro versions usually
- outperform libc versions.
- HAVE_MMAP (default: defined as 1)
- Define to non-zero to optionally make malloc() use mmap() to
- allocate very large blocks.
- HAVE_MREMAP (default: defined as 0 unless Linux libc set)
- Define to non-zero to optionally make realloc() use mremap() to
- reallocate very large blocks.
- USE_ARENAS (default: the same as HAVE_MMAP)
- Enable support for multiple arenas, allocated using mmap().
- malloc_getpagesize (default: derived from system #includes)
- Either a constant or routine call returning the system page size.
- HAVE_USR_INCLUDE_MALLOC_H (default: NOT defined)
- Optionally define if you are on a system with a /usr/include/malloc.h
- that declares struct mallinfo. It is not at all necessary to
- define this even if you do, but will ensure consistency.
- INTERNAL_SIZE_T (default: size_t)
- Define to a 32-bit type (probably `unsigned int') if you are on a
- 64-bit machine, yet do not want or need to allow malloc requests of
- greater than 2^31 to be handled. This saves space, especially for
- very small chunks.
- _LIBC (default: NOT defined)
- Defined only when compiled as part of the Linux libc/glibc.
- Also note that there is some odd internal name-mangling via defines
- (for example, internally, `malloc' is named `mALLOc') needed
- when compiling in this case. These look funny but don't otherwise
- affect anything.
- LACKS_UNISTD_H (default: undefined)
- Define this if your system does not have a <unistd.h>.
- MORECORE (default: sbrk)
- The name of the routine to call to obtain more memory from the system.
- MORECORE_FAILURE (default: -1)
- The value returned upon failure of MORECORE.
- MORECORE_CLEARS (default 1)
- The degree to which the routine mapped to MORECORE zeroes out
- memory: never (0), only for newly allocated space (1) or always
- (2). The distinction between (1) and (2) is necessary because on
- some systems, if the application first decrements and then
- increments the break value, the contents of the reallocated space
- are unspecified.
- DEFAULT_TRIM_THRESHOLD
- DEFAULT_TOP_PAD
- DEFAULT_MMAP_THRESHOLD
- DEFAULT_MMAP_MAX
- Default values of tunable parameters (described in detail below)
- controlling interaction with host system routines (sbrk, mmap, etc).
- These values may also be changed dynamically via mallopt(). The
- preset defaults are those that give best performance for typical
- programs/systems.
- DEFAULT_CHECK_ACTION
- When the standard debugging hooks are in place, and a pointer is
- detected as corrupt, do nothing (0), print an error message (1),
- or call abort() (2).
-
-
-*/
+ Linux. It is also reported to work on WIN32 platforms.
+ People also report using it in stand-alone embedded systems.
+
+ The implementation is in straight, hand-tuned ANSI C. It is not
+ at all modular. (Sorry!) It uses a lot of macros. To be at all
+ usable, this code should be compiled using an optimizing compiler
+ (for example gcc -O3) that can simplify expressions and control
+ paths. (FAQ: some macros import variables as arguments rather than
+ declare locals because people reported that some debuggers
+ otherwise get confused.)
+
+ OPTION DEFAULT VALUE
+
+ Compilation Environment options:
+
+ __STD_C derived from C compiler defines
+ WIN32 NOT defined
+ HAVE_MEMCPY defined
+ USE_MEMCPY 1 if HAVE_MEMCPY is defined
+ HAVE_MMAP defined as 1
+ MMAP_CLEARS 1
+ HAVE_MREMAP 0 unless linux defined
+ USE_ARENAS the same as HAVE_MMAP
+ malloc_getpagesize derived from system #includes, or 4096 if not
+ HAVE_USR_INCLUDE_MALLOC_H NOT defined
+ LACKS_UNISTD_H NOT defined unless WIN32
+ LACKS_SYS_PARAM_H NOT defined unless WIN32
+ LACKS_SYS_MMAN_H NOT defined unless WIN32
+
+ Changing default word sizes:
+
+ INTERNAL_SIZE_T size_t
+ MALLOC_ALIGNMENT 2 * sizeof(INTERNAL_SIZE_T)
+
+ Configuration and functionality options:
+
+ USE_DL_PREFIX NOT defined
+ USE_PUBLIC_MALLOC_WRAPPERS NOT defined
+ USE_MALLOC_LOCK NOT defined
+ MALLOC_DEBUG NOT defined
+ REALLOC_ZERO_BYTES_FREES 1
+ MALLOC_FAILURE_ACTION errno = ENOMEM, if __STD_C defined, else no-op
+ TRIM_FASTBINS 0
+
+ Options for customizing MORECORE:
+
+ MORECORE sbrk
+ MORECORE_FAILURE -1
+ MORECORE_CONTIGUOUS 1
+ MORECORE_CANNOT_TRIM NOT defined
+ MORECORE_CLEARS 1
+ MMAP_AS_MORECORE_SIZE (1024 * 1024)
+
+ Tuning options that are also dynamically changeable via mallopt:
+
+ DEFAULT_MXFAST 64
+ DEFAULT_TRIM_THRESHOLD 128 * 1024
+ DEFAULT_TOP_PAD 0
+ DEFAULT_MMAP_THRESHOLD 128 * 1024
+ DEFAULT_MMAP_MAX 65536
+
+ There are several other #defined constants and macros that you
+ probably don't want to touch unless you are extending or adapting malloc. */
/*
-
-* Compile-time options for multiple threads:
-
- USE_PTHREADS, USE_THR, USE_SPROC
- Define one of these as 1 to select the thread interface:
- POSIX threads, Solaris threads or SGI sproc's, respectively.
- If none of these is defined as non-zero, you get a `normal'
- malloc implementation which is not thread-safe. Support for
- multiple threads requires HAVE_MMAP=1. As an exception, when
- compiling for GNU libc, i.e. when _LIBC is defined, then none of
- the USE_... symbols have to be defined.
-
- HEAP_MIN_SIZE
- HEAP_MAX_SIZE
- When thread support is enabled, additional `heap's are created
- with mmap calls. These are limited in size; HEAP_MIN_SIZE should
- be a multiple of the page size, while HEAP_MAX_SIZE must be a power
- of two for alignment reasons. HEAP_MAX_SIZE should be at least
- twice as large as the mmap threshold.
- THREAD_STATS
- When this is defined as non-zero, some statistics on mutex locking
- are computed.
-
+ __STD_C should be nonzero if using ANSI-standard C compiler, a C++
+ compiler, or a C compiler sufficiently close to ANSI to get away
+ with it.
*/
-
-
-
-/* Preliminaries */
-
#ifndef __STD_C
-#if defined (__STDC__)
-#define __STD_C 1
-#else
-#if __cplusplus
+#if defined(__STDC__) || defined(__cplusplus)
#define __STD_C 1
#else
#define __STD_C 0
-#endif /*__cplusplus*/
-#endif /*__STDC__*/
+#endif
#endif /*__STD_C*/
+
+/*
+ Void_t* is the pointer type that malloc should say it returns
+*/
+
#ifndef Void_t
-#if __STD_C
+#if (__STD_C || defined(WIN32))
#define Void_t void
#else
#define Void_t char
@@ -303,57 +249,59 @@
#endif /*Void_t*/
#if __STD_C
-# include <stddef.h> /* for size_t */
-# if defined _LIBC || defined MALLOC_HOOKS
-# include <stdlib.h> /* for getenv(), abort() */
-# endif
+#include <stddef.h> /* for size_t */
+#include <stdlib.h> /* for getenv(), abort() */
#else
-# include <sys/types.h>
-# if defined _LIBC || defined MALLOC_HOOKS
-extern char* getenv();
-# endif
+#include <sys/types.h>
#endif
-/* Macros for handling mutexes and thread-specific data. This is
- included early, because some thread-related header files (such as
- pthread.h) should be included before any others. */
-#include "thread-m.h"
-
#ifdef __cplusplus
extern "C" {
#endif
-#include <errno.h>
-#include <stdio.h> /* needed for malloc_stats */
+/* define LACKS_UNISTD_H if your system does not have a <unistd.h>. */
+/* #define LACKS_UNISTD_H */
-/*
- Compile-time options
-*/
+#ifndef LACKS_UNISTD_H
+#include <unistd.h>
+#endif
+/* define LACKS_SYS_PARAM_H if your system does not have a <sys/param.h>. */
+
+/* #define LACKS_SYS_PARAM_H */
+
+
+#include <stdio.h> /* needed for malloc_stats */
+#include <errno.h> /* needed for optional MALLOC_FAILURE_ACTION */
-/*
- Debugging:
-
- Because freed chunks may be overwritten with link fields, this
- malloc will often die when freed memory is overwritten by user
- programs. This can be very effective (albeit in an annoying way)
- in helping track down dangling pointers.
-
- If you compile with -DMALLOC_DEBUG, a number of assertion checks are
- enabled that will catch more memory errors. You probably won't be
- able to make much sense of the actual assertion errors, but they
- should help you locate incorrectly overwritten memory. The
- checking is fairly extensive, and will slow down execution
- noticeably. Calling malloc_stats or mallinfo with MALLOC_DEBUG set will
- attempt to check every non-mmapped allocated and free chunk in the
- course of computing the summaries. (By nature, mmapped regions
- cannot be checked very much automatically.)
-
- Setting MALLOC_DEBUG may also be helpful if you are trying to modify
- this code. The assertions in the check routines spell out in more
- detail the assumptions and invariants underlying the algorithms.
+/*
+ Debugging:
+
+ Because freed chunks may be overwritten with bookkeeping fields, this
+ malloc will often die when freed memory is overwritten by user
+ programs. This can be very effective (albeit in an annoying way)
+ in helping track down dangling pointers.
+
+ If you compile with -DMALLOC_DEBUG, a number of assertion checks are
+ enabled that will catch more memory errors. You probably won't be
+ able to make much sense of the actual assertion errors, but they
+ should help you locate incorrectly overwritten memory. The checking
+ is fairly extensive, and will slow down execution
+ noticeably. Calling malloc_stats or mallinfo with MALLOC_DEBUG set
+ will attempt to check every non-mmapped allocated and free chunk in
+ the course of computing the summmaries. (By nature, mmapped regions
+ cannot be checked very much automatically.)
+
+ Setting MALLOC_DEBUG may also be helpful if you are trying to modify
+ this code. The assertions in the check routines spell out in more
+ detail the assumptions and invariants underlying the algorithms.
+
+ Setting MALLOC_DEBUG does NOT provide an automated mechanism for
+ checking that all accesses to malloced memory stay within their
+ bounds. However, there are several add-ons and adaptations of this
+ or other mallocs available that do this.
*/
#if MALLOC_DEBUG
@@ -365,42 +313,197 @@ extern "C" {
/*
INTERNAL_SIZE_T is the word-size used for internal bookkeeping
- of chunk sizes. On a 64-bit machine, you can reduce malloc
- overhead by defining INTERNAL_SIZE_T to be a 32 bit `unsigned int'
- at the expense of not being able to handle requests greater than
- 2^31. This limitation is hardly ever a concern; you are encouraged
- to set this. However, the default version is the same as size_t.
+ of chunk sizes.
+
+ The default version is the same as size_t.
+
+ While not strictly necessary, it is best to define this as an
+ unsigned type, even if size_t is a signed type. This may avoid some
+ artificial size limitations on some systems.
+
+ On a 64-bit machine, you may be able to reduce malloc overhead by
+ defining INTERNAL_SIZE_T to be a 32 bit `unsigned int' at the
+ expense of not being able to handle more than 2^3