dmalloc 原文 翻译整理

http://blog.csdn.net/cardinal_508/article/details/5553387

L13 从快速入门开始（Quickstart） 

这个库是一个文件中所有简化用法中最常见的：FTP下载它，编译它（-03），并连接到其他程序。

全部编译时默认选择合理值在大多数平台。

之后你也可以单步编译多次并动态调整选项。 

This library is all in one file to simplify the most common usage:  ftp it, compile it (-O3), and link it into another program.

All of  the compile-time options default to reasonable values for use on  most platforms. 

You might later want to step through various  compile-time and dynamic tuning options. 

L21 为了方便起见，一个包含文件为代码用于这个分配器在：ftp://gee.cs.oswego.edu/pub/misc/malloc-2.8.4.h 

你并不是真的需要这个.h头文件除非你不调用在你的系统中定义的包含文件的的函数。

这个.h头文件仅仅包含了使用这个分配器在ANSI c/c++系统所必须引用的文件。

只要你不改变编译选项关于命名或者调整参数。

如果你这么做了，你要创建你自己的malloc.h文件包含全部的设置，情况如下。

注意你也许已经使用的c库默认包含一个分配器基于这个分配器的一个版本（比如linux）。

您可能还需要使用在此文件中自定义设置，以避免与相关库版本之间的消费。

For convenience, an include file for code using this malloc is at:     ftp://gee.cs.oswego.edu/pub/misc/malloc-2.8.4.h 

You don't really need this .h file unless you call functions not  defined in your system include files.

The .h file contains only the  excerpts from this file needed for using this malloc on ANSI C/C++  systems,

so long as you haven't changed compile-time options about  naming and tuning parameters. 

If you do, then you can create your own malloc.h that does include all settings by cutting at the point indicated below.

Note that 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 to customize settings or to avoid overheads associated with library versions.

 

L35 重要统计： 

Vital statistics: 

L37 支持指针/size_t代表：  4或8字节

size_t必须必须是一个相同宽度无符号类型指针。

（如果你使用的是一个老系统，声明size_t有符号类型或者需要一个不同宽度的指针，你可以用之前发布的这个分配器（2.72版本）。

Supported pointer/size_t representation:       4 or 8 bytes

size_t MUST be an unsigned type of the same width as pointers.

(If you are using an ancient system that declares size_t as a signed type, or need it to be a different width than pointers,

you can use a previous release of this malloc (e.g. 2.7.2) supporting these.)

 

L44 对齐 8字节（默认）这满足几乎现在所有的机器和C编译器。

不过，你能定义MALLOC_ALIGNMENT去使它变宽如果必要的话（提高到128字节）以更多的空间为代价。

 Alignment:                                     8 bytes (default)

This suffices for nearly all current machines and C compilers. However,

you can define MALLOC_ALIGNMENT to be wider than this if necessary (up to 128bytes), at the expense of using more space.

 

L49 每块分配的最小开销： 4或8字节（如果尺寸为4字节）    8或16字节（如果尺寸为8字节）

每一个被分配的块有一个隐藏字开销支持尺寸、状态信息和校验字如果尾部定义。 

Minimum overhead per allocated chunk:   4 or  8 bytes (if 4byte sizes), 8 or 16 bytes (if 8byte sizes)
Each malloced chunk has a hidden word of overhead holding size and status information, and additional cross-check word if FOOTERS is defined.

L55 最小分配尺寸：4-字节 ptrs（不太明白）:  16字节 （包含开销）8-字节 ptrs: 32字节 （包含开销）

甚至一个零字节请求（即malloc（0））反回一个指针意义上的最小分配尺寸。

最大的开销浪费（即许多额外的字节分配比申请的内存）是小于或等于最小尺寸，

除了请求大于等于mmap_threshold(数极限)维护树，最糟糕的浪费情况是关于32字节额外从系统页（最小树单元）；

代表4096或8192字节。（我的理解是树中存储内存空间的额外空间消耗为32字节）

Minimum allocated size: 4-byte ptrs:  16 bytes    (including overhead), 8-byte ptrs:  32 bytes    (including overhead)

Even a request for zero bytes (i.e., malloc(0)) returns a pointer to something of the minimum allocatable size.

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 about 32 bytes plus the remainder from a system page (the minimal mmap unit); typically 4096 or 8192 bytes.

 

L67  安全：静态安全; 或多或少可选的

安全的内存分配是指引起严重错误影响的恶意的代码能够调用分配器（例如，释放没有分配或者覆盖结尾部分的块）。

这个内存分配保证在基础堆下不修改任何内存单元。即静态的变量，甚至在错误用法面前。

另外检测大多数释放不当和reallocs。

所有这一切，只要静态记录对分配器本身无损害的其他一些方法。这只是一个安全方面 - 这些检查没有，不能检测所有可能的编程错误。

如果脚注定义为非零，每个分配的块带有一个额外的校验字去验证从这个空间被分配的块。

每一个用于执行分配程序的校验字是相同的，但是不同交叉执行，这样外部制作的假块不能被释放。

拒绝破坏堆内存的释放/realloc提高了安全性，除了预防检查之外的那些总是静态的去写。

已时间和空间开销为代价也进一步提高了安全性（注意脚注也同样有价值用于MSPACES）。

默认情况下检测到错误导致程序中断（调用“中断”）。你可以重载这个替换运行错误的部分通过定义PROCEED_ON_ERROR。

在这种情况下，坏的释放不会有影响，并且一个内存分配遇到坏地址引起的用户覆盖将忽略坏地址的退出指针和索引的所有已知内存。

这应该仍然是合适的方案，假设面对所有可能的程序错误，虽然他们可能耗尽内存因为内存不会被释放回收。

如果你不喜欢这些选择，你可以定义CORRUPTION_ERROR_ACTION 和 USAGE_ERROR_ACTION去执行任意其他的规则。

并且如果你肯定你的程序使用内存分配没有错误和陷阱，你可以定义INSECURE为1，或许会有一个小幅度的性能提升。

 

 Security: static-safe; optionally more or less
The "security" of malloc refers to the ability of malicious code to accentuate the effects of errors

(for example, freeing space that is not currently malloc'ed or overwriting past the ends of chunks) in code that calls malloc. 

This malloc guarantees not to modify any memory locations below the base of heap, i.e., static variables, even in the presence of usage errors. 

The routines additionally detect most improper frees  and reallocs. 

All this holds as long as the static bookkeeping for malloc itself is not corrupted by some other means. 

This is only one aspect of security -- these checks do not, and cannot, detect all possible programming errors.

If FOOTERS is defined nonzero, then each allocated chunk carries an additional check word to verify that it was malloced from its space. 

These check words are the same within each execution of a program using malloc, but differ across executions,

so externally crafted fake chunks cannot be freed.

This improves security by rejecting frees/reallocs that could corrupt heap memory, in addition to the checks preventing writes to statics that are always on. 

This may further improve security at the expense of time and space overhead.  (Note that FOOTERS may also be worth using with MSPACES.)

By default detected errors cause the program to abort (calling "abort()").

You can override this to instead proceed past errors by defining PROCEED_ON_ERROR. 

In this case, a bad free has no effect, and a malloc that encounters a bad address

caused by user overwrites will ignore the bad address by dropping pointers and indices to all known memory.

This may be appropriate for programs that should continue if at all possible in the face of programming errors,

although they may run out of memory because dropped memory is never reclaimed.

If you don't like either of these options, you can define CORRUPTION_ERROR_ACTION and USAGE_ERROR_ACTION to do anything else.

And if if you are sure that your program using malloc has no errors or vulnerabilities,

you can define INSECURE to 1, which might (or might not) provide a small performance improvement.

 

L107 线程安全：没有线程安全除非USE_LOCKS被定义，当USE_LOCKS被定义，每一个公共调用内存分配，释放，

等等周围任何一个内部线程互斥或者win32互斥（挂起在win32）.

这样不是特别快，并且可能是一个主要瓶颈。

这样的设计仅仅提供一个最低保护在并发环境，并提供一个基础的扩展。

如果你使用内存分配在一个并发程序，考虑用

nedmalloc(http://www.nedprod.com/programs/portable/nedmalloc/)或者

ptmalloc（看http://www.malloc.de）得到内存分配的新版本。

 

Thread-safety: NOT thread-safe unless USE_LOCKS defined When USE_LOCKS is defined, each public call to malloc, free,
etc is surrounded with either a pthread mutex or a win32 spinlock (depending on WIN32). This is not especially fast, and
can be a major bottleneck.  It is designed only to provide minimal protection in concurrent environments, and to provide a
basis for extensions.  If you are using malloc in a concurrent program, consider instead using

nedmalloc(http://www.nedprod.com/programs/portable/nedmalloc/) or

ptmalloc (See http://www.malloc.de), which are derived  from versions of this malloc.

 

L119 系统需求： 任意组合多核并且/或者 MMAP/MUNMAP。

这个内存分配可以用于unix sbrk或任意仿真（调用CALL_MMAP / CALL_NUMMAP）别且/或者 mmap/munmap

或任意仿真（调用CALL_MMAP/CALL_MUNMAP）得到或释放系统内存。

在大多unix系统上，倾向于最好启用MORECORE和MMAP工作。在WIN32，仿真基于虚分配。也用C库函数命令如memset。 

System requirements: Any combination of MORECORE and/or MMAP/MUNMAP
       This malloc can use unix sbrk or any emulation (invoked using the CALL_MORECORE macro) and/or mmap/munmap

or any emulation(invoked using CALL_MMAP/CALL_MUNMAP) to get and release system memory. 

On most unix systems, it tends to work best if both MORECORE and MMAP are enabled. 

On Win32, it uses emulations based on VirtualAlloc. It also uses common C library functions like memset.

 

L128 承诺：我相信它符合单unix规格（看http://www.unix.org）。同样SVID/XPG,ANSI C, 并且其他可能也一样。 

 Compliance: I believe it is compliant with the Single Unix Specification(See http://www.unix.org).

Also SVID/XPG, ANSI C, and probably others as well.

 

L132 算法概述

这不是最快的，最节省空间的，最轻量级的，或者可调的分配器。然而他几乎是最快的，也几乎是在节省空间的，轻量级并可调的。

坚持平等对待这些因素结构，一个良好的通用分配器对于集成的内存分配程序。 

 

 * Overview of algorithms

  This is not the fastest, most space-conserving, most portable, or 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 malloc-intensive programs.

 

L140 在大多数情况下，这个内存分配器是最恰当的。

一般来说，它选择最合适的现存块为一个请求，节点打破了大约最近最少使用的顺序（这个策略一般来维护低碎块率。）

然而，对于小于256字节的请求，背离了最合适的情况时没有一个恰好合适可用的块，用邻近的小空间请求，同样打破了大约最近最少使用的顺序。

（这增加了本地小块的分配）并且对于非常大的请求（大于等于256字节默认）依靠系统内存映射机制，如果支持。（这样有助于避免可能携带的内存碎块仅用于大块。）

 

In most ways, this malloc is a best-fit allocator. Generally, it  chooses the best-fitting existing chunk for a request,

with ties broken in approximately least-recently-used order.

(This strategy normally maintains low fragmentation.) However, for requests less than 256bytes,

it deviates from best-fit when there is not an exactly fitting available chunk by preferring to use space adjacent to

that used for the previous small request, as well as by breaking ties in approximately most-recently-used order.

(These enhance locality of series of small allocations.)  And for very large requests (>= 256Kb by default),

it relies on system memory mapping facilities, if supported. 

(This helps avoid carrying around and possibly fragmenting memory used only for large chunks.)

 

L153 所有操作（除了malloc_stats和mallinfo）运行次数受常数因子的位的尺寸约束，不计算任何的清理calloc或拷贝realloc，

或者MORECORE周围的动作和MMAP成时间比例的一定数量不连续区域被返回系统内存分配，通常为仅为1.

在真实的应用中，你能选择禁止部分遍历用NO_SEGMENT_TRAVERSAL，

保证边界内执行甚至当系统内存分配返回不连续的空间，典型的消耗更多的内存并且增加碎块。

 

All operations (except malloc_stats and mallinfo) have execution  times that are bounded by a constant factor of the number of bits in a size_t,

not counting any clearing in calloc or copying in realloc, or actions surrounding MORECORE and MMAP that have times proportional to the number

of non-contiguous regions returned by system allocation routines, which is often just 1.

In real-time applications, you can optionally suppress segment traversals using  NO_SEGMENT_TRAVERSAL,

which assures bounded execution even when system allocators return non-contiguous spaces,

at the typical  expense of carrying around more memory and increased fragmentation.

L164 实现不是完全模块化和过度使用宏。也许有朝一日所有的C编译器现在不能作的蛮力扩展嵌入模块码能做到，但是现在他们似乎是不足的。 

 The implementation is not very modular and seriously overuses macros.

Perhaps someday all C compilers will do as good a job inlining modular code as can now be done by brute-force expansion, but now, enough of them seem not to.

 

一些编译器发送许多的警告，关于代码死掉/不能找到仅仅在一些平台上，并且也关于一些故意不用的无符号类型。所有一只能被忽略的原因。 

Some compilers issue a lot of warnings about code that is dead/unreachable only on some platforms, and also about intentional uses of negation on unsigned types.

All known cases of each can be ignored. 

一个冗长，但是高等级的描述，看http://gee.cs.oswego.edu/dl/html/malloc.html 

For a longer but out of date high-level description, see http://gee.cs.oswego.edu/dl/html/malloc.html

 

L178 MSSPACES 

如果定义了MSSPACES，然后加入malloc,free,等.中，这个文件也定义 mspace_malloc, mspace_free,等。

这些是常规版本malloc采取"mspace"参数获得引用create_mspace，去控制所有的内部记录。

如果 ONLY_MSPACES被定义，仅这些版本被编译。

这样如果你想使用这个内存分配器为仅仅一些内存分配并且你的系统malloc作其他的，你可以仅编译ONLY_MSPACES并然后做一些事情像...

   static mspace myspace = create_mspace(0,0);//例子

   #define mymalloc(bytes)  mspace_malloc(mymspace, bytes)

 

* MSPACES
  If MSPACES is defined, then in addition to malloc, free, etc., this file also defines mspace_malloc, mspace_free, etc.

These are versions of malloc routines that take an "mspace" argument obtained using create_mspace, to control all internal bookkeeping.

If ONLY_MSPACES is defined, only these versions are compiled.

So if you would like to use this allocator for only some allocations, and your system malloc for others,

you can compile with ONLY_MSPACES and then do something like...

    static mspace mymspace = create_mspace(0,0); // for example
    #define mymalloc(bytes)  mspace_malloc(mymspace, bytes)

 

L189 注解：如果你仅需一个mspace实例，你可以替换用USE_DL_PREFIX去重注全局malloc

你同样能建立线程局部内存分配存储mspaces像局部线程。例如：

     static __thread mspace tlms = 0;

     void* tlmalloc(size_t bytes)

     {

          if(tlms == 0) tlms = create_mspace(0,0);

          return mspace_malloc(tlms, bytes); 

     }

     void tlfree(void* mem) { mspace_free(tlms,mem);}

除非 FOOTERS是定义的，每一个mspace是独立完成的，你不能从一个自由分配到另一个（尽管一致性检查是弱的，错误的用法不总是被捕获）。

如果FOOTERS被定义，每一个块携带着一个标签标明它源于mspace，并且释放指向它的源spaces。

 

  (Note: If you only need one instance of an mspace, you can instead use "USE_DL_PREFIX" to relabel the global malloc.)

  You can similarly create thread-local allocators by storing mspaces as thread-locals. For example:
    static __thread mspace tlms = 0;
    void*  tlmalloc(size_t bytes) {
      if (tlms == 0) tlms = create_mspace(0, 0);
      return mspace_malloc(tlms, bytes);
    }
    void  tlfree(void* mem) { mspace_free(tlms, mem); }

  Unless FOOTERS is defined, each mspace is completely independent.

You cannot allocate from one and free to another (although conformance is only weakly checked, so usage errors are not always caught).

If FOOTERS is defined, then each chunk carries around a tag indicating its originating mspace, and frees are directed to their originating spaces.

 

L208--------------------------------编译选项-----------------------------------------------------

谨慎建立size_t类型数学常量值的定义。一些系统，默认的值不是自动适应size_t精度除非他们明确的定义，你也能使用符号值MAX_SIZE_T，SIZE_T_ONE,等如下。

 

WIN32                       默认：定义如果 _WIN32定义

定义WIN32建立默认为MS环境并编译器。另外默认为unix。

注意的是，似乎有一些malloc的情况下，这可能不是一个纯粹的简易替换为WIN32的malloc：

随机查看失败从Win32 GDI API的原由也许是在一些视频驱动执行当像素缓存被分配，并且虚拟缓存溢出的BUG。

因为 dlmalloc使用一个小的默认粒度为64k的，像素缓存可能经常跨虚拟缓存范围分配当用微软的内存分配器时。

你能解决这个使用VirtualAlloc（）和VirtualFree（）为所有的像素缓存宁可用malloc()。

如果这是不可能的，重新编译这个malloc带着一个大的DEFAULT_GRANULARITY。 

 -------------------------  Compile-time options ---------------------------

Be careful in setting #define values for numerical constants of typesize_t.

On some systems, literal values are not automatically extended to size_t precision unless they are explicitly casted.

You can also use the symbolic values MAX_SIZE_T, SIZE_T_ONE, etc below.

WIN32                    default: defined if _WIN32 defined
  Defining WIN32 sets up defaults for MS environment and compilers. 

Otherwise defaults are for unix. Beware that there seem to be some cases where this malloc might not be a pure drop-in replacement for Win32 malloc:

Random-looking failures from Win32 GDI API's (eg; SetDIBits()) may be due to bugs in some video driver implementations when pixel buffers are malloc()ed,

and the region spans more than one VirtualAlloc()ed region. Because dlmalloc uses a small (64Kb)  default granularity,

pixel buffers may straddle virtual allocation regions more often than when using the Microsoft allocator. 

You can avoid this by using VirtualAlloc() and VirtualFree() for all pixel buffers rather than using malloc(). 

If this is not possible, recompile this malloc with a larger DEFAULT_GRANULARITY.

L229 MALLOC_ALIGNMENT                          默认: (size_t)8

为控制块分配出来的最小对齐。他必须是一个两个单位的至少8位，甚至一个小的机器位置是足够的。

虽然可以定义比这个大的。注解：然而8字节数据结构队列代码是最佳的。

 

MALLOC_ALIGNMENT         default: (size_t)8
  Controls the minimum alignment for malloc'ed chunks. 

It must be a power of two and at least 8, even on machines for which smaller alignments would suffice.

It may be defined as larger than this though.

Note however that code and data structures are optimized for the case of 8-byte alignment.

 

L236 MSPACES                                        默认：0（false）

如果是true，编译支持独立的内存分配空间。这仅仅在HAVE_MMAP为真的情况下支持

 

MSPACES                  default: 0 (false)
  If true, compile in support for independent allocation spaces.  This is only supported if HAVE_MMAP is true.

 

L204 ONLY_MSPACES                               默认：0 （false）

如果是true，仅编译在mspace版本，非正式版本。

 

======================= Version 2.8.6  ============================================

USE_LOCKS default: 0 (false)
Causes each call to each public routine to be surrounded with
pthread or WIN32 mutex lock/unlock. (If set true, this can be
overridden on a per-mspace basis for mspace versions.) If set to a
non-zero value other than 1, locks are used, but their
implementation is left out, so lock functions must be supplied manually,
as described below.

USE_SPIN_LOCKS default: 1 iff USE_LOCKS and spin locks available
If true, uses custom spin locks for locking. This is currently
supported only gcc >= 4.1, older gccs on x86 platforms, and recent
MS compilers. Otherwise, posix locks or win32 critical sections are
used.

USE_RECURSIVE_LOCKS default: not defined
If defined nonzero, uses recursive (aka reentrant) locks, otherwise
uses plain mutexes. This is not required for malloc proper, but may
be needed for layered allocators such as nedmalloc.

LOCK_AT_FORK default: not defined
If defined nonzero, performs pthread_atfork upon initialization
to initialize child lock while holding parent lock. The implementation
assumes that pthread locks (not custom locks) are being used. In other
cases, you may need to customize the implementation.

FOOTERS default: 0
If true, provide extra checking and dispatching by placing information in the footers of allocated chunks. This adds space and time overhead.

INSECURE default: 0
If true, omit checks for usage errors and heap space overwrites.

USE_DL_PREFIX default: NOT defined
Causes compiler to prefix all public routines with the string 'dl'.
This can be useful when you only want to use this malloc in one part
of a program, using your regular system malloc elsewhere.

MALLOC_INSPECT_ALL default: NOT defined
If defined, compiles malloc_inspect_all and mspace_inspect_all, that
perform traversal of all heap space. Unless access to these
functions is otherwise restricted, you probably do not want to
include them in secure implementations.

ABORT default: defined as abort()
Defines how to abort on failed checks. On most systems, a failed
check cannot die with an "assert" or even print an informative
message, because the underlying print routines in turn call malloc,
which will fail again. Generally, the best policy is to simply call
abort(). It's not very useful to do more than this because many
errors due to overwriting will show up as address faults (null, odd
addresses etc) rather than malloc-triggered checks, so will also
abort. Also, most compilers know that abort() does not return, so
can better optimize code conditionally calling it.

PROCEED_ON_ERROR default: defined as 0 (false)
Controls whether detected bad addresses cause them to bypassed
rather than aborting. If set, detected bad arguments to free and
realloc are ignored. And all bookkeeping information is zeroed out
upon a detected overwrite of freed heap space, thus losing the
ability to ever return it from malloc again, but enabling the
application to proceed. If PROCEED_ON_ERROR is defined, the
static variable malloc_corruption_error_count is compiled in
and can be examined to see if errors have occurred. This option
generates slower code than the default abort policy.

DEBUG default: NOT defined
The DEBUG setting is mainly intended for people trying to modify
this code or diagnose problems when porting to new platforms.
However, it may also be able to better isolate user errors than just
using runtime checks. The assertions in the check routines spell
out in more detail the assumptions and invariants underlying the
algorithms. The checking is fairly extensive, and will slow down
execution noticeably. Calling malloc_stats or mallinfo with DEBUG
set will attempt to check every non-mmapped allocated and free chunk
in the course of computing the summaries.

ABORT_ON_ASSERT_FAILURE default: defined as 1 (true)
Debugging assertion failures can be nearly impossible if your
version of the assert macro causes malloc to be called, which will
lead to a cascade of further failures, blowing the runtime stack.
ABORT_ON_ASSERT_FAILURE cause assertions failures to call abort(),
which will usually make debugging easier.

MALLOC_FAILURE_ACTION default: sets errno to ENOMEM, or no-op on win32
The action to take before "return 0" when malloc fails to be able to
return memory because there is none available.

HAVE_MORECORE default: 1 (true) unless win32 or ONLY_MSPACES
True if this system supports sbrk or an emulation of it.

MORECORE default: sbrk
The name of the sbrk-style system routine to call to obtain more
memory. See below for guidance on writing custom MORECORE
functions. The type of the argument to sbrk/MORECORE varies across
systems. It cannot be size_t, because it supports negative
arguments, so it is normally the signed type of the same width as
size_t (sometimes declared as "intptr_t"). It doesn't much matter
though. Internally, we only call it with arguments less than half
the max value of a size_t, which should work across all reasonable
possibilities, although sometimes generating compiler warnings.

MORECORE_CONTIGUOUS default: 1 (true) if HAVE_MORECORE
If true, take advantage of fact that consecutive calls to MORECORE
with positive arguments always return contiguous increasing
addresses. This is true of unix sbrk. It does not hurt too much to
set it true anyway, since malloc copes with non-contiguities.
Setting it false when definitely non-contiguous saves time
and possibly wasted space it would take to discover this though.

MORECORE_CANNOT_TRIM default: NOT defined
True if MORECORE cannot release space back to the system when given
negative arguments. This is generally necessary only if you are
using a hand-crafted MORECORE function that cannot handle negative
arguments.

NO_SEGMENT_TRAVERSAL default: 0
If non-zero, suppresses traversals of memory segments
returned by either MORECORE or CALL_MMAP. This disables
merging of segments that are contiguous, and selectively
releasing them to the OS if unused, but bounds execution times.

HAVE_MMAP default: 1 (true)
True if this system supports mmap or an emulation of it. If so, and
HAVE_MORECORE is not true, MMAP is used for all system
allocation. If set and HAVE_MORECORE is true as well, MMAP is
primarily used to directly allocate very large blocks. It is also
used as a backup strategy in cases where MORECORE fails to provide
space from system. Note: A single call to MUNMAP is assumed to be
able to unmap memory that may have be allocated using multiple calls
to MMAP, so long as they are adjacent.

HAVE_MREMAP default: 1 on linux, else 0
If true realloc() uses mremap() to re-allocate large blocks and
extend or shrink allocation spaces.

MMAP_CLEARS default: 1 except on WINCE.
True if mmap clears memory so calloc doesn't need to. This is true
for standard unix mmap using /dev/zero and on WIN32 except for WINCE.

USE_BUILTIN_FFS default: 0 (i.e., not used)
Causes malloc to use the builtin ffs() function to compute indices.
Some compilers may recognize and intrinsify ffs to be faster than the
supplied C version. Also, the case of x86 using gcc is special-cased
to an asm instruction, so is already as fast as it can be, and so
this setting has no effect. Similarly for Win32 under recent MS compilers.
(On most x86s, the asm version is only slightly faster than the C version.)

malloc_getpagesize default: derive from system includes, or 4096.
The system page size. To the extent possible, this malloc manages
memory from the system in page-size units. This may be (and
usually is) a function rather than a constant. This is ignored
if WIN32, where page size is determined using getSystemInfo during
initialization.

USE_DEV_RANDOM default: 0 (i.e., not used)
Causes malloc to use /dev/random to initialize secure magic seed for
stamping footers. Otherwise, the current time is used.

NO_MALLINFO default: 0
If defined, don't compile "mallinfo". This can be a simple way
of dealing with mismatches between system declarations and
those in this file.

MALLINFO_FIELD_TYPE default: size_t
The type of the fields in the mallinfo struct. This was originally
defined as "int" in SVID etc, but is more usefully defined as
size_t. The value is used only if HAVE_USR_INCLUDE_MALLOC_H is not set

NO_MALLOC_STATS default: 0
If defined, don't compile "malloc_stats". This avoids calls to
fprintf and bringing in stdio dependencies you might not want.

REALLOC_ZERO_BYTES_FREES default: not defined
This should be set if a call to realloc with zero bytes should
be the same as a call to free. Some people think it should. Otherwise,
since this malloc returns a unique pointer for malloc(0), so does
realloc(p, 0).

LACKS_UNISTD_H, LACKS_FCNTL_H, LACKS_SYS_PARAM_H, LACKS_SYS_MMAN_H
LACKS_STRINGS_H, LACKS_STRING_H, LACKS_SYS_TYPES_H, LACKS_ERRNO_H
LACKS_STDLIB_H LACKS_SCHED_H LACKS_TIME_H

default: NOT defined unless on WIN32
Define these if your system does not have these header files.
You might need to manually insert some of the declarations they provide.

DEFAULT_GRANULARITY default: page size if MORECORE_CONTIGUOUS,
system_info.dwAllocationGranularity in WIN32,otherwise 64K.
Also settable using mallopt(M_GRANULARITY, x)
The unit for allocating and deallocating memory from the system. On
most systems with contiguous MORECORE, there is no reason to
make this more than a page. However, systems with MMAP tend to
either require or encourage larger granularities. You can increase
this value to prevent system allocation functions to be called so
often, especially if they are slow. The value must be at least one
page and must be a power of two. Setting to 0 causes initialization
to either page size or win32 region size. (Note: In previous
versions of malloc, the equivalent of this option was called
"TOP_PAD")

DEFAULT_TRIM_THRESHOLD default: 2MB
Also settable using mallopt(M_TRIM_THRESHOLD, x)
The maximum amount of unused top-most memory to keep before
releasing via malloc_trim in free(). Automatic trimming is mainly
useful in long-lived programs using contiguous MORECORE. Because
trimming via sbrk can be slow on some systems, and can sometimes be
wasteful (in cases where programs immediately afterward allocate
more large chunks) the value should be high enough so that your
overall system performance would improve by releasing this much
memory. As a rough guide, you might set to a value close to the
average size of a process (program) running on your system.
Releasing this much memory would allow such a process to run in
memory. Generally, it is worth tuning trim thresholds when a
program undergoes phases where several large chunks are allocated
and released in ways that can reuse each other's storage, perhaps
mixed with phases where there are no such chunks at all. The trim
value must be greater than page size to have any useful effect. To
disable trimming completely, you can set to MAX_SIZE_T. Note that the trick
some people use of mallocing a huge space and then freeing it at
program startup, in an attempt to reserve system memory, doesn't
have the intended effect under automatic trimming, since that memory
will immediately be returned to the system.

DEFAULT_MMAP_THRESHOLD default: 256K
Also settable using mallopt(M_MMAP_THRESHOLD, x)
The request size threshold for using MMAP to directly service a
request. Requests of at least this size that cannot be allocated
using already-existing space will be serviced via mmap. (If enough
normal freed space already exists it is used instead.) Using mmap
segregates relatively large chunks of memory so that they can be
individually obtained and released from the host system. A request
serviced through mmap is never reused by any other request (at least
not directly; the system may just so happen to remap successive
requests to the same locations). Segregating space in this way has
the benefits that: Mmapped space can always be individually released
back to the system, which helps keep the system level memory demands
of a long-lived program low. Also, mapped memory doesn't become
`locked' between other chunks, as can happen with normally allocated
chunks, which means that even trimming via malloc_trim would not
release them. However, it has the disadvantage that the space
cannot be reclaimed, consolidated, and then used to service later
requests, as happens with normal chunks. The advantages of mmap
nearly always outweigh disadvantages for "large" chunks, but the
value of "large" may vary across systems. The default is an
empirically derived value that works well in most systems. You can
disable mmap by setting to MAX_SIZE_T.

MAX_RELEASE_CHECK_RATE default: 4095 unless not HAVE_MMAP
The number of consolidated frees between checks to release
unused segments when freeing. When using non-contiguous segments,
especially with multiple mspaces, checking only for topmost space
doesn't always suffice to trigger trimming. To compensate for this,
free() will, with a period of MAX_RELEASE_CHECK_RATE (or the
current number of segments, if greater) try to release unused
segments to the OS when freeing chunks that result in
consolidation. The best value for this parameter is a compromise
between slowing down frees with relatively costly checks that
rarely trigger versus holding on to unused memory. To effectively
disable, set to MAX_SIZE_T. This may lead to a very slight speed
improvement at the expense of carrying around more memory.