|Project Name||Stars||Downloads||Repos Using This||Packages Using This||Most Recent Commit||Total Releases||Latest Release||Open Issues||License||Language|
|Mimalloc||8,592||a day ago||6||April 15, 2022||278||mit||C|
|mimalloc is a compact general purpose allocator with excellent performance.|
|Gcpp||777||4 years ago||7||mit||C++|
|Experimental deferred and unordered destruction library for C++|
|Sx||773||a year ago||bsd-2-clause||C|
|Portable base library for C programmers, designed for performance and simplicity.|
|Tinyalloc||664||2 years ago||1||apache-2.0||C|
|malloc / free replacement for unmanaged, linear memory situations (e.g. WASM, embedded devices...)|
|Heap_allocator||639||4 years ago||1||mit||C|
|A simple heap memory allocator in ~200 lines.|
|Scala Offheap||533||1||4 years ago||1||November 03, 2015||15||bsd-3-clause||Scala|
|Experimental type-safe off-heap memory for Scala.|
|Larray||390||5||10 months ago||6||November 27, 2017||24||apache-2.0||Scala|
|Large off-heap arrays and mmap files for Scala and Java|
|Diehard||351||2 years ago||4||gpl-2.0||C|
|DieHard: An error-resistant memory allocator for Windows, Linux, and Mac OS X|
|Heap Layers||345||3 months ago||3||apache-2.0||C++|
|Heap Layers: An Extensible Memory Allocation Infrastructure|
|Ig Memtrace||341||4 years ago||5||bsd-2-clause||C#|
|Memory Tracing Software|
Latest release tag:
Latest stable tag:
mimalloc is a drop-in replacement for
malloc and can be used in other programs
without code changes, for example, on dynamically linked ELF-based systems (Linux, BSD, etc.) you can use it as:
> LD_PRELOAD=/usr/lib/libmimalloc.so myprogram
It also includes a robust way to override the default allocator in Windows. Notable aspects of the design include:
freeoperations, and another one for concurrent
freeoperations. Free-ing from another thread can now be a single CAS without needing sophisticated coordination between threads. Since there will be thousands of separate free lists, contention is naturally distributed over the heap, and the chance of contending on a single location will be low -- this is quite similar to randomized algorithms like skip lists where adding a random oracle removes the need for a more complex algorithm.
master: latest stable release (based on
dev: development branch for mimalloc v1. Use this branch for submitting PR's.
dev-slice: development branch for mimalloc v2. This branch is downstream of
v2.x version has a new algorithm for managing internal mimalloc pages that tends to reduce memory usage
and fragmentation compared to mimalloc
v1.x (especially for large workloads). Should otherwise have similar performance
(see below); please report if you observe any significant performance regression.
v2.1.2: Fixes build issues on freeBSD, musl, and C17 (UE 5.1.1). Reduce code size/complexity
by removing regions and segment-cache's and only use arenas with improved memory purging -- this may improve memory
usage as well for larger services. Renamed options for consistency. Improved Valgrind and ASAN checking.
v2.1.1: Fixes build issues on some platforms.
v2.1.0: Improved support dynamic overriding on Windows 11. Improved tracing precision
with asan and Valgrind, and added Windows event tracing ETW (contributed by Xinglong He). Created an OS
abstraction layer to make it easier to port and separate platform dependent code (in
src/prim). Fixed C++ STL compilation on older Microsoft C++ compilers, and various small bug fixes.
v2.0.9: Supports building with asan and improved Valgrind support.
Support abitrary large alignments (in particular for
Added C++ STL allocators attached to a specific heap (thanks @vmarkovtsev).
Heap walks now visit all object (including huge objects). Support Windows nano server containers (by Johannes Schindelin,@dscho). Various small bug fixes.
v2.0.7: Initial support for Valgrind for leak testing and heap block overflow
support for attaching heaps to a speficic memory area (only in v2). Fix
realloc behavior for zero size blocks, remove restriction to integral multiple of the alignment in
alloc_align, improved aligned allocation performance, reduced contention with many threads on few processors (thank you @dposluns!), vs2022 support, support
v2.0.6: fix fallback path for aligned OS allocation on Windows, improve Windows aligned allocation
even when compiling with older SDK's, fix dynamic overriding on macOS Monterey, fix MSVC C++ dynamic overriding, fix
warnings under Clang 14, improve performance if many OS threads are created and destroyed, fix statistics for large object
allocations, using MIMALLOC_VERBOSE=1 has no maximum on the number of error messages, various small fixes.
v2.0.5 (alpha): fix malloc override on
Windows 11, fix compilation with musl, potentially reduced
committed memory, add
bin/minject for Windows,
improved wasm support, faster aligned allocation,
various small fixes.
Special thanks to:
mimalloc is used in various large scale low-latency services and programs, for example:
ide/vs2019/mimalloc.sln in Visual Studio 2019 and build.
mimalloc project builds a static library (in
out/msvc-x64), while the
mimalloc-override project builds a DLL for overriding malloc
in the entire program.
cmake1 as the build system:
> mkdir -p out/release > cd out/release > cmake ../.. > make
This builds the library as a shared (dynamic)
.dylib), a static library (
as a single object file (
> sudo make install (install the library and header files in
You can build the debug version which does many internal checks and maintains detailed statistics as:
> mkdir -p out/debug > cd out/debug > cmake -DCMAKE_BUILD_TYPE=Debug ../.. > make
This will name the shared library as
Finally, you can build a secure version that uses guard pages, encrypted free lists, etc., as:
> mkdir -p out/secure > cd out/secure > cmake -DMI_SECURE=ON ../.. > make
This will name the shared library as
ccmake2 instead of
to see and customize all the available build options.
sudo apt-get install cmake
sudo apt-get install cmake-curses-gui
You can also directly build the single
src/static.c file as part of your project without
cmake at all. Make sure to also add the mimalloc
include directory to the include path.
The preferred usage is including
<mimalloc.h>, linking with
the shared- or static library, and using the
mi_malloc API exclusively for allocation. For example,
> gcc -o myprogram -lmimalloc myfile.c
mimalloc uses only safe OS calls (
VirtualAlloc) and can co-exist
with other allocators linked to the same program.
If you use
cmake, you can simply use:
find_package(mimalloc 1.4 REQUIRED)
CMakeLists.txt to find a locally installed mimalloc. Then use either:
target_link_libraries(myapp PUBLIC mimalloc)
to link with the shared (dynamic) library, or:
target_link_libraries(myapp PUBLIC mimalloc-static)
to link with the static library. See
test\CMakeLists.txt for an example.
For best performance in C++ programs, it is also recommended to override the
delete operators. For convience, mimalloc provides
mimalloc-new-delete.h which does this for you -- just include it in a single(!) source file in your project.
In C++, mimalloc also provides the
mi_stl_allocator struct which implements the
You can pass environment variables to print verbose messages (
and statistics (
MIMALLOC_SHOW_STATS=1) (in the debug version):
> env MIMALLOC_SHOW_STATS=1 ./cfrac 175451865205073170563711388363 175451865205073170563711388363 = 374456281610909315237213 * 468551 heap stats: peak total freed unit normal 2: 16.4 kb 17.5 mb 17.5 mb 16 b ok normal 3: 16.3 kb 15.2 mb 15.2 mb 24 b ok normal 4: 64 b 4.6 kb 4.6 kb 32 b ok normal 5: 80 b 118.4 kb 118.4 kb 40 b ok normal 6: 48 b 48 b 48 b 48 b ok normal 17: 960 b 960 b 960 b 320 b ok heap stats: peak total freed unit normal: 33.9 kb 32.8 mb 32.8 mb 1 b ok huge: 0 b 0 b 0 b 1 b ok total: 33.9 kb 32.8 mb 32.8 mb 1 b ok malloc requested: 32.8 mb committed: 58.2 kb 58.2 kb 58.2 kb 1 b ok reserved: 2.0 mb 2.0 mb 2.0 mb 1 b ok reset: 0 b 0 b 0 b 1 b ok segments: 1 1 1 -abandoned: 0 pages: 6 6 6 -abandoned: 0 mmaps: 3 mmap fast: 0 mmap slow: 1 threads: 0 elapsed: 2.022s process: user: 1.781s, system: 0.016s, faults: 756, reclaims: 0, rss: 2.7 mb
The above model of using the
mi_ prefixed API is not always possible
though in existing programs that already use the standard malloc interface,
and another option is to override the standard malloc interface
completely and redirect all calls to the mimalloc library instead .
You can set further options either programmatically (using
mi_option_set), or via environment variables:
MIMALLOC_SHOW_STATS=1: show statistics when the program terminates.
MIMALLOC_VERBOSE=1: show verbose messages.
MIMALLOC_SHOW_ERRORS=1: show error and warning messages.
MIMALLOC_PURGE_DELAY=N: the delay in
Nmilli-seconds (by default
10) after which mimalloc will purge OS pages that are not in use. This signals to the OS that the underlying physical memory can be reused which can reduce memory fragmentation especially in long running (server) programs. Setting
0purges immediately when a page becomes unused which can improve memory usage but also decreases performance. Setting
Nto a higher value like
100can improve performance (sometimes by a lot) at the cost of potentially using more memory at times. Setting it to
-1disables purging completely.
MIMALLOC_ARENA_EAGER_COMMIT=1: turns on eager commit for the large arenas (usually 1GiB) from which mimalloc allocates segments and pages. This is by default only enabled on overcommit systems (e.g. Linux) but enabling it explicitly on other systems (like Windows or macOS) may improve performance. Note that eager commit only increases the commit but not the actual the peak resident set (rss) so it is generally ok to enable this.
Further options for large workloads and services:
MIMALLOC_USE_NUMA_NODES=N: pretend there are at most
NNUMA nodes. If not set, the actual NUMA nodes are detected at runtime. Setting
Nto 1 may avoid problems in some virtual environments. Also, setting it to a lower number than the actual NUMA nodes is fine and will only cause threads to potentially allocate more memory across actual NUMA nodes (but this can happen in any case as NUMA local allocation is always a best effort but not guaranteed).
MIMALLOC_ALLOW_LARGE_OS_PAGES=1: use large OS pages (2MiB) when available; for some workloads this can significantly improve performance. Use
MIMALLOC_VERBOSEto check if the large OS pages are enabled -- usually one needs to explicitly allow large OS pages (as on Windows and Linux). However, sometimes the OS is very slow to reserve contiguous physical memory for large OS pages so use with care on systems that can have fragmented memory (for that reason, we generally recommend to use
MIMALLOC_RESERVE_HUGE_OS_PAGESinstead whenever possible).
Nis the number of 1GiB huge OS pages. This reserves the huge pages at startup and sometimes this can give a large (latency) performance improvement on big workloads. Usually it is better to not use
MIMALLOC_ALLOW_LARGE_OS_PAGES=1in combination with this setting. Just like large OS pages, use with care as reserving contiguous physical memory can take a long time when memory is fragmented (but reserving the huge pages is done at startup only once). Note that we usually need to explicitly enable huge OS pages (as on Windows and Linux)). With huge OS pages, it may be beneficial to set the setting
Nis 1 by default) to delay the initial
Nsegments (of 4MiB) of a thread to not allocate in the huge OS pages; this prevents threads that are short lived and allocate just a little to take up space in the huge OS page area (which cannot be purged). The huge pages are usually allocated evenly among NUMA nodes. We can use
Nis the numa node (starting at 0) to allocate all the huge pages at a specific numa node instead.
Use caution when using
fork in combination with either large or huge OS pages: on a fork, the OS uses copy-on-write
for all pages in the original process including the huge OS pages. When any memory is now written in that area, the
OS will copy the entire 1GiB huge page (or 2MiB large page) which can cause the memory usage to grow in large increments.
mimalloc can be build in secure mode by using the
-DMI_SECURE=ON flags in
cmake. This build enables various mitigations
to make mimalloc more robust against exploits. In particular:
As always, evaluate with care as part of an overall security strategy as all of the above are mitigations but not guarantees.
When mimalloc is built using debug mode, various checks are done at runtime to catch development errors.
Overriding the standard
new) can be done either dynamically or statically.
This is the recommended way to override the standard malloc interface.
On these ELF-based systems we preload the mimalloc shared
library so all calls to the standard
malloc interface are
resolved to the mimalloc library.
> env LD_PRELOAD=/usr/lib/libmimalloc.so myprogram
You can set extra environment variables to check that mimalloc is running, like:
> env MIMALLOC_VERBOSE=1 LD_PRELOAD=/usr/lib/libmimalloc.so myprogram
or run with the debug version to get detailed statistics:
> env MIMALLOC_SHOW_STATS=1 LD_PRELOAD=/usr/lib/libmimalloc-debug.so myprogram
On macOS we can also preload the mimalloc shared
library so all calls to the standard
malloc interface are
resolved to the mimalloc library.
> env DYLD_INSERT_LIBRARIES=/usr/lib/libmimalloc.dylib myprogram
Note that certain security restrictions may apply when doing this from the shell.
Overriding on Windows is robust and has the particular advantage to be able to redirect all malloc/free calls that go through the (dynamic) C runtime allocator, including those from other DLL's or libraries.
The overriding on Windows requires that you link your program explicitly with
the mimalloc DLL and use the C-runtime library as a DLL (using the
mimalloc-redirect32.dll) must be put
in the same folder as the main
mimalloc-override.dll at runtime (as it is a dependency).
The redirection DLL ensures that all calls to the C runtime malloc API get redirected to
To ensure the mimalloc DLL is loaded at run-time it is easiest to insert some
call to the mimalloc API in the
main function, like
(or use the
/INCLUDE:mi_version switch on the linker). See the
for an example on how to use this. For best performance on Windows with C++, it
is also recommended to also override the
delete operations (by including
mimalloc-new-delete.h a single(!) source file in your project).
The environment variable
MIMALLOC_DISABLE_REDIRECT=1 can be used to disable dynamic
overriding at run-time. Use
MIMALLOC_VERBOSE=1 to check if mimalloc was successfully redirected.
(Note: in principle, it is possible to even patch existing executables without any recompilation
if they are linked with the dynamic C runtime (
ucrtbase.dll) -- just put the
into the import table (and put
mimalloc-redirect.dll in the same folder)
Such patching can be done for example with CFF Explorer).
On Unix-like systems, you can also statically link with mimalloc to override the standard
malloc interface. The recommended way is to link the final program with the
mimalloc single object file (
mimalloc.o). We use
an object file instead of a library file as linkers give preference to
that over archives to resolve symbols. To ensure that the standard
malloc interface resolves to the mimalloc library, link it as the first
object file. For example:
> gcc -o myprogram mimalloc.o myfile1.c ...
Another way to override statically that works on all platforms, is to
link statically to mimalloc (as shown in the introduction) and include a
header file in each source file that re-defines
malloc etc. to
This is provided by
mimalloc-override.h. This only works reliably though if all sources are
under your control or otherwise mixing of pointers from different heaps may occur!
Generally, we recommend using the standard allocator with memory tracking tools, but mimalloc
can also be build to support the address sanitizer or the excellent Valgrind tool.
Moreover, it can be build to support Windows event tracing (ETW).
This has a small performance overhead but does allow detecting memory leaks and byte-precise
buffer overflows directly on final executables. See also the
test/test-wrong.c file to test with various tools.
To build with valgrind support, use the
MI_TRACK_VALGRIND=ON cmake option:
> cmake ../.. -DMI_TRACK_VALGRIND=ON
This can also be combined with secure mode or debug mode. You can then run your programs directly under valgrind:
> valgrind <myprogram>
If you rely on overriding
free by mimalloc (instead of using the
mi_free API directly),
you also need to tell
valgrind to not intercept those calls itself, and use:
> MIMALLOC_SHOW_STATS=1 valgrind --soname-synonyms=somalloc=*mimalloc* -- <myprogram>
By setting the
MIMALLOC_SHOW_STATS environment variable you can check that mimalloc is indeed
used and not the standard allocator. Even though the Valgrind option
--soname-synonyms, this also
works when overriding with a static library or object file. Unfortunately, it is not possible to
dynamically override mimalloc using
LD_PRELOAD together with
See also the
test/test-wrong.c file to test with
Valgrind support is in its initial development -- please report any issues.
To build with the address sanitizer, use the
-DMI_TRACK_ASAN=ON cmake option:
> cmake ../.. -DMI_TRACK_ASAN=ON
This can also be combined with secure mode or debug mode. You can then run your programs as:'
> ASAN_OPTIONS=verbosity=1 <myprogram>
When you link a program with an address sanitizer build of mimalloc, you should
generally compile that program too with the address sanitizer enabled.
For example, assuming you build mimalloc in
clang -g -o test-wrong -Iinclude test/test-wrong.c out/debug/libmimalloc-asan-debug.a -lpthread -fsanitize=address -fsanitize-recover=address
Since the address sanitizer redirects the standard allocation functions, on some platforms (macOSX for example)
it is required to compile mimalloc with
Adress sanitizer support is in its initial development -- please report any issues.
Event tracing for Windows (ETW) provides a high performance way to capture all allocations though
mimalloc and analyze them later. To build with ETW support, use the
-DMI_TRACK_ETW=ON cmake option.
You can then capture an allocation trace using the Windows performance recorder (WPR), using the
src/prim/windows/etw-mimalloc.wprp profile. In an admin prompt, you can use:
> wpr -start src\prim\windows\etw-mimalloc.wprp -filemode > <my_mimalloc_program> > wpr -stop <my_mimalloc_program>.etl
and then open
<my_mimalloc_program>.etl in the Windows Performance Analyzer (WPA), or
use a tool like TraceControl that is specialized for analyzing mimalloc traces.
Last update: 2021-01-30
We tested mimalloc against many other top allocators over a wide range of benchmarks, ranging from various real world programs to synthetic benchmarks that see how the allocator behaves under more extreme circumstances. In our benchmark suite, mimalloc outperforms other leading allocators (jemalloc, tcmalloc, Hoard, etc), and has a similar memory footprint. A nice property is that it does consistently well over the wide range of benchmarks.
General memory allocators are interesting as there exists no algorithm that is optimal -- for a given allocator one can usually construct a workload where it does not do so well. The goal is thus to find an allocation strategy that performs well over a wide range of benchmarks without suffering from (too much) underperformance in less common situations.
As always, interpret these results with care since some benchmarks test synthetic
or uncommon situations that may never apply to your workloads. For example, most
allocators do not do well on
xmalloc-testN but that includes even the best
industrial allocators like jemalloc and tcmalloc that are used in some of
the world's largest systems (like Chrome or FreeBSD).
Also, the benchmarks here do not measure the behaviour on very large and long-running server workloads,
or worst-case latencies of allocation. Much work has gone into
mimalloc to work well on such
workloads (for example, to reduce virtual memory fragmentation on long-running services)
but such optimizations are not always reflected in the current benchmark suite.
Testing on the 16-core AMD 5950x processor at 3.4Ghz (4.9Ghz boost), with with 32GiB memory at 3600Mhz, running Ubuntu 20.04 with glibc 2.31 and GCC 9.3.0.
We measure three versions of mimalloc: the main version
the new v2.0 beta version as
xmi (tag:v2.0.0), and the main version in secure mode as
The other allocators are
Google's tcmalloc (
tc, tag:gperftools-2.8.1) used in Chrome,
Facebook's jemalloc (
je, tag:5.2.1) by Jason Evans used in Firefox and FreeBSD,
the Intel thread building blocks allocator (
rp,tag:1.4.1) by Mattias Jansson,
the original scalable Hoard (git:d880f72) allocator by Emery Berger ,
the memory compacting Mesh (git:67ff31a) allocator by
Bobby Powers et al ,
and finally the default system allocator (
glibc, 2.31) (based on PtMalloc2).
Any benchmarks ending in
N run on all 32 logical cores in parallel.
Results are averaged over 10 runs and reported relative
to mimalloc (where 1.2 means it took 1.2× longer to run).
The legend also contains the overall relative score between the
allocators where 100 points is the maximum if an allocator is fastest on
The single threaded cfrac benchmark by Dave Barrett is an implementation of continued fraction factorization which uses many small short-lived allocations. All allocators do well on such common usage, where mimalloc is just a tad faster than tcmalloc and jemalloc.
The leanN program is interesting as a large realistic and concurrent workload of the Lean theorem prover compiling its own standard library, and there is a 13% speedup over tcmalloc. This is quite significant: if Lean spends 20% of its time in the allocator that means that mimalloc is 1.6× faster than tcmalloc here. (This is surprising as that is not measured in a pure allocation benchmark like alloc-test. We conjecture that we see this outsized improvement here because mimalloc has better locality in the allocation which improves performance for the other computations in a program as well).
The single threaded redis benchmark again show that most allocators do well on such workloads.
The larsonN server benchmark by Larson and Krishnan  allocates and frees between threads. They observed this behavior (which they call bleeding) in actual server applications, and the benchmark simulates this. Here, mimalloc is quite a bit faster than tcmalloc and jemalloc probably due to the object migration between different threads.
The mstressN workload performs many allocations and re-allocations, and migrates objects between threads (as in larsonN). However, it also creates and destroys the N worker threads a few times keeping some objects alive beyond the life time of the allocating thread. We observed this behavior in many larger server applications.
The rptestN benchmark by Mattias Jansson is a allocator test originally designed for rpmalloc, and tries to simulate realistic allocation patterns over multiple threads. Here the differences between allocators become more apparent.
The second benchmark set tests specific aspects of the allocators and shows even more extreme differences between them.
The alloc-test, by OLogN Technologies AG, is a very allocation intensive benchmark doing millions of allocations in various size classes. The test is scaled such that when an allocator performs almost identically on alloc-test1 as alloc-testN it means that it scales linearly.
The sh6bench and sh8bench benchmarks are developed by MicroQuill as part of SmartHeap. In sh6bench mimalloc does much better than the others (more than 2.5× faster than jemalloc). We cannot explain this well but believe it is caused in part by the "reverse" free-ing pattern in sh6bench. The sh8bench is a variation with object migration between threads; whereas tcmalloc did well on sh6bench, the addition of object migration causes it to be 10× slower than before.
The xmalloc-testN benchmark by Lever and Boreham  and Christian Eder, simulates an asymmetric workload where some threads only allocate, and others only free -- they observed this pattern in larger server applications. Here we see that the mimalloc technique of having non-contended sharded thread free lists pays off as it outperforms others by a very large margin. Only rpmalloc, tbb, and glibc also scale well on this benchmark.
The cache-scratch benchmark by Emery Berger , and introduced with the Hoard allocator to test for passive-false sharing of cache lines. With a single thread they all perform the same, but when running with multiple threads the potential allocator induced false sharing of the cache lines can cause large run-time differences. Crundal  describes in detail why the false cache line sharing occurs in the tcmalloc design, and also discusses how this can be avoided with some small implementation changes. Only the tbb, rpmalloc and mesh allocators also avoid the cache line sharing completely, while Hoard and glibc seem to mitigate the effects. Kukanov and Voss  describe in detail how the design of tbb avoids the false cache line sharing.
For completeness, here are the results on a big Amazon c5.18xlarge instance consisting of a 2×18-core Intel Xeon (Cascade Lake) at 3.4GHz (boost 3.5GHz) with 144GiB ECC memory, running Ubuntu 20.04 with glibc 2.31, GCC 9.3.0, and Clang 10.0.0. This time, the mimalloc allocators (mi, xmi, and smi) were compiled with the Clang compiler instead of GCC. The results are similar to the AMD results but it is interesting to see the differences in the larsonN, mstressN, and xmalloc-testN benchmarks.
The following figure shows the peak working set (rss) of the allocators on the benchmarks (on the c5.18xlarge instance).
Note that the xmalloc-testN memory usage should be disregarded as it allocates more the faster the program runs. Similarly, memory usage of larsonN, mstressN, rptestN and sh8bench can vary depending on scheduling and speed. Nevertheless, we hope to improve the memory usage on mstressN and rptestN (just as cfrac, larsonN and sh8bench have a small working set which skews the results).
 Emery D. Berger, Kathryn S. McKinley, Robert D. Blumofe, and Paul R. Wilson. Hoard: A Scalable Memory Allocator for Multithreaded Applications the Ninth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS-IX). Cambridge, MA, November 2000. pdf
 P. Larson and M. Krishnan. Memory allocation for long-running server applications. In ISMM, Vancouver, B.C., Canada, 1998. pdf
 D. Grunwald, B. Zorn, and R. Henderson. Improving the cache locality of memory allocation. In R. Cartwright, editor, Proceedings of the Conference on Programming Language Design and Implementation, pages 177186, New York, NY, USA, June 1993. pdf
 J. Barnes and P. Hut. A hierarchical O(n*log(n)) force-calculation algorithm. Nature, 324:446-449, 1986.
 C. Lever, and D. Boreham. Malloc() Performance in a Multithreaded Linux Environment. In USENIX Annual Technical Conference, Freenix Session. San Diego, CA. Jun. 2000. Available at https://github.com/kuszmaul/SuperMalloc/tree/master/tests
 Timothy Crundal. Reducing Active-False Sharing in TCMalloc. 2016. CS16S1 project at the Australian National University. pdf
 Alexey Kukanov, and Michael J Voss. The Foundations for Scalable Multi-Core Software in Intel Threading Building Blocks. Intel Technology Journal 11 (4). 2007
 Bobby Powers, David Tench, Emery D. Berger, and Andrew McGregor. Mesh: Compacting Memory Management for C/C++ In Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI'19), June 2019, pages 333-346.
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
v2.0.3 (beta): improved WASM support, improved macOS support and performance (including
M1), improved performance for v2 for large objects, Python integration improvements, more standard
installation directories, various small fixes.
v2.0.2 (beta): support M1, better installation layout on Linux, fix
thread_id on Android, prefer 2-6TiB area for aligned allocation to work better on pre-windows 8, various small fixes.
v2.0.1 (beta): fix bug in arena allocation for huge pages, improved aslr on large allocations, initial M1 support (still experimental).
v2.0.0: beta release 2.0: new slice algorithm for managing internal mimalloc pages.
v1.7.0: stable release 1.7: support explicit user provided memory regions, more precise statistics,
improve macOS overriding, initial support for Apple M1, improved DragonFly support, faster memcpy on Windows, various small fixes.
v1.6.7: stable release 1.6: using standard C atomics, passing tsan testing, improved
handling of failing to commit on Windows, add
mi_process_info api call.
v1.6.4: stable release 1.6: improved error recovery in low-memory situations,
support for IllumOS and Haiku, NUMA support for Vista/XP, improved NUMA detection for AMD Ryzen, ubsan support.
v1.6.3: stable release 1.6: improved behavior in out-of-memory situations, improved malloc zones on macOS,
build PIC static libraries by default, add option to abort on out-of-memory, line buffered statistics.
v1.6.2: stable release 1.6: fix compilation on Android, MingW, Raspberry, and Conda,
stability fix for Windows 7, fix multiple mimalloc instances in one executable, fix
fix aligned debug padding.
v1.6.1: stable release 1.6: minor updates (build with clang-cl, fix alignment issue for small objects).
v1.6.0: stable release 1.6: fixed potential memory leak, improved overriding
and thread local support on FreeBSD, NetBSD, DragonFly, and macOSX. New byte-precise
heap block overflow detection in debug mode (besides the double-free detection and free-list
corruption detection). Add
nodiscard attribute to most allocation functions.
MIMALLOC_PAGE_RESET by default. New reclamation strategy for abandoned heap pages
for better memory footprint.
v1.5.0: stable release 1.5: improved free performance, small bug fixes.
v1.4.0: stable release 1.4: improved performance for delayed OS page reset,
more eager concurrent free, addition of STL allocator, fixed potential memory leak.
v1.3.0: stable release 1.3: bug fixes, improved randomness and stronger
free list encoding in secure mode.
v1.2.2: stable release 1.2: minor updates.
v1.2.0: stable release 1.2: bug fixes, improved secure mode (free list corruption checks, double free mitigation). Improved dynamic overriding on Windows.
v1.1.0: stable release 1.1.
v1.0.8: pre-release 8: more robust windows dynamic overriding, initial huge page support.
v1.0.6: pre-release 6: various performance improvements.