Check out my first novel, midnight's simulacra!

Allocators: Difference between revisions

From dankwiki
No edit summary
No edit summary
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
As of 2023, [[Glibc]] uses [https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c ptmalloc2] aka Doug Lea's malloc with arena modifications by Wolfram Gloger. It's critical to know that allocations equal to or larger than <tt>MMAP_THRESHOLD</tt> (by default 128KiB) will be serviced by anonymous <tt>[[mmap]]</tt>.
==Multiprocessing-suitable dropins==
==Multiprocessing-suitable dropins==
* [http://www.hoard.org/ Hoard] - Emery Berger's multiprocessor-geared allocator, a drop-in <tt>malloc(3)</tt> replacement
* [http://www.hoard.org/ Hoard] - Emery Berger's multiprocessor-geared allocator, a drop-in <tt>malloc(3)</tt> replacement
* [http://goog-perftools.sourceforge.net/doc/tcmalloc.html TCMalloc] - Google's "Thread-Caching malloc", another <tt>malloc(3)</tt> drop-in for multiprocessing
* [http://goog-perftools.sourceforge.net/doc/tcmalloc.html TCMalloc] - Google's "Thread-Caching malloc", another <tt>malloc(3)</tt> drop-in for multiprocessing
* [https://github.com/mjansson/rpmalloc rpmalloc] the Rampant Pixel Mallocator, lock-free, 16-byte aligned
==Realtime-suitable dropins==
* "[http://rtportal.upv.es/rtmalloc/ TLSF - The Two-Level Segregate Fit allocator]" from the [http://www.gii.upv.es/ Industrial Informatics and Real-Time Systems Group]


==Arena==
==Arena==
Line 29: Line 34:


==References==
==References==
* [http://memoryallocators.com/ MemoryAllocators.com] is replete with good information
* Joseph Attardi and Neelakanth Nadgir's "[http://developers.sun.com/solaris/articles/multiproc/multiproc.html A Comparison of Memory Allocators in Multiprocessors]", Sun Developer Network June 2003
* Joseph Attardi and Neelakanth Nadgir's "[http://developers.sun.com/solaris/articles/multiproc/multiproc.html A Comparison of Memory Allocators in Multiprocessors]", Sun Developer Network June 2003
* Schneider, Antonopoulos and Nikolopoulos, "[http://www.ics.forth.gr/~dsn/papers/ismm06.pdf Scalable Locality-Conscious Multithreaded Memory Allocation]", ISMM 2006.
* Schneider, Antonopoulos and Nikolopoulos, "[http://www.ics.forth.gr/~dsn/papers/ismm06.pdf Scalable Locality-Conscious Multithreaded Memory Allocation]", ISMM 2006.
* [http://rtportal.upv.es/rtmalloc/ TLSF] - The Two-Level Segregate Fit allocator from the [http://www.gii.upv.es/ Industrial Informatics and Real-Time Systems Group]
* Masmano, Ripoll et al, "[http://rtportal.upv.es/rtmalloc/node/69 A constant-time dynamic storage allocator for real-time systems], ''Realtime Systems'' Vol. 40 Num. 2, November 2008.
* Masmano, Ripoll et al, "[http://rtportal.upv.es/rtmalloc/node/69 A constant-time dynamic storage allocator for real-time systems], ''Realtime Systems'' Vol. 40 Num. 2, November 2008.
* Great page reagrding [http://g.oswego.edu/dl/html/malloc.html dlalloc], Doug Lea's allocator
* Wilson, Johnstone, Neely, Boles, "Dynamic Storage Allocation: A Survey and Critical Review"

Latest revision as of 07:41, 11 June 2023

As of 2023, Glibc uses ptmalloc2 aka Doug Lea's malloc with arena modifications by Wolfram Gloger. It's critical to know that allocations equal to or larger than MMAP_THRESHOLD (by default 128KiB) will be serviced by anonymous mmap.

Multiprocessing-suitable dropins

  • Hoard - Emery Berger's multiprocessor-geared allocator, a drop-in malloc(3) replacement
  • TCMalloc - Google's "Thread-Caching malloc", another malloc(3) drop-in for multiprocessing
  • rpmalloc the Rampant Pixel Mallocator, lock-free, 16-byte aligned

Realtime-suitable dropins

Arena

Slab

Linux kernel variants

The following data is collected from kernel 2.6.30:

  • SLAB: The original. From the Kconfig help:
The regular slab allocator that is established and known to work
well in all environments. It organizes cache hot objects in
per cpu and per node queues.
  • SLUB (Christoph Lameter, 2007) reduced the size of the slab object queue and improved scalability for many processors (LKML). From the Kconfig help:
SLUB is a slab allocator that minimizes cache line usage
instead of managing queues of cached objects (SLAB approach).
Per cpu caching is realized using slabs of objects instead
of queues of objects. SLUB can use memory efficiently
and has enhanced diagnostics. SLUB is the default choice for
a slab allocator.

References