Allocators

(23 intermediate revisions by the same user not shown)

Line 1:

* [http://rtportal.upv.es/rtmalloc/ TLSF] - The Two-Level Segregate Fit allocator

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==

* [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

* [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==

==Slab==

* Jeff Bonwick's [http://citeseer.ist.psu.edu/bonwick94slab.html classic 1994 creation], first published in the context of the SunOS 5.4 kernel

* Bonwick and Adams extended slab in "[http://www.usenix.org/event/usenix01/bonwick.html Magazines and Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary Resources]," from USENIX 2001.

** Vmem: Fast, general backend store for slab, claimed to be "the first allocator that can satisfy allocations and frees of any size in guaranteed constant time."

** Magazines: Per-CPU memory allocators and caching scheme

===Linux kernel variants===

The following data is collected from kernel 2.6.30:

* SLAB: The original. From the Kconfig help:

<pre>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.</pre>

* [http://lwn.net/Articles/229984/ SLUB] (Christoph Lameter, 2007) reduced the size of the slab object queue and improved scalability for many processors ([http://article.gmane.org/gmane.linux.kernel/510692 LKML]). From the Kconfig help:

<pre>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.</pre>

* [http://lwn.net/Articles/311502/ SLQB] (Nick Piggin, 2008)

* SLOB ([http://article.gmane.org/gmane.linux.kernel/344062 LKML])

* [http://www.nabble.com/Differences-between-SLUB-SLAB-SLOB-SLQB-td22818541.html Differences] between SL*Bs

==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

* Schneider, Antonopoulos and Nikolopoulos, "[http://www.ics.forth.gr/~dsn/papers/ismm06.pdf Scalable Locality-Conscious Multithreaded Memory Allocation]", ISMM 2006.

* 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"

Allocators: Difference between revisions

Dank (talk | contribs)

@@ Line 1: / Line 1: @@
-* [http://rtportal.upv.es/rtmalloc/ TLSF] - The Two-Level Segregate Fit allocator
+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==
+* [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
+* [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==
+==Slab==
+* Jeff Bonwick's [http://citeseer.ist.psu.edu/bonwick94slab.html classic 1994 creation], first published in the context of the SunOS 5.4 kernel
+* Bonwick and Adams extended slab in "[http://www.usenix.org/event/usenix01/bonwick.html Magazines and Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary Resources]," from USENIX 2001.
+** Vmem: Fast, general backend store for slab, claimed to be "the first allocator that can satisfy allocations and frees of any size in guaranteed constant time."
+** Magazines: Per-CPU memory allocators and caching scheme
+===Linux kernel variants===
+The following data is collected from kernel 2.6.30:
+* SLAB: The original. From the Kconfig help:
+<pre>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.</pre>
+* [http://lwn.net/Articles/229984/ SLUB] (Christoph Lameter, 2007) reduced the size of the slab object queue and improved scalability for many processors ([http://article.gmane.org/gmane.linux.kernel/510692 LKML]). From the Kconfig help:
+<pre>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.</pre>
+* [http://lwn.net/Articles/311502/ SLQB] (Nick Piggin, 2008)
+* SLOB ([http://article.gmane.org/gmane.linux.kernel/344062 LKML])
+* [http://www.nabble.com/Differences-between-SLUB-SLAB-SLOB-SLQB-td22818541.html Differences] between SL*Bs
+==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
+* Schneider, Antonopoulos and Nikolopoulos, "[http://www.ics.forth.gr/~dsn/papers/ismm06.pdf Scalable Locality-Conscious Multithreaded Memory Allocation]", ISMM 2006.
+* 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"