Exploring ptmalloc: Memory Management in Linux C++ Programs

This article is the second part of the series "Exploring C++ Memory Management" and focuses on the classic glibc memory allocator ptmalloc . It explains how ptmalloc manages memory for C++ programs on Linux, the design trade‑offs, and the engineering details behind its implementation.

1. Overview

ptmalloc is the default memory manager in GNU C Library (glibc) and provides the malloc / free API used by most Linux server applications. Compared with modern allocators such as jemalloc and tcmalloc, ptmalloc’s performance is lower, but it remains widely deployed.

Goal: make user allocation and deallocation more efficient, reduce lock contention in multithreaded environments, and balance memory usage with system‑call overhead.

2. Memory Management Architecture

ptmalloc divides memory into a main arena (the primary allocation area) and one or more non‑main arenas . Each arena holds a pre‑allocated region of memory and manages both used and free chunks.

The main arena can obtain memory via sbrk() (heap) and mmap() , while non‑main arenas use only mmap() . Threads first try to lock their private arena; if unavailable, they traverse the circular list of arenas to find an unlocked one.

2.1 Data Structures

Memory is split into chunks using a boundary‑tag method. The basic unit is malloc_chunk , which contains fields such as:

mchunk_prev_size : size of the previous free chunk

mchunk_size : size of the current chunk

Flag bits indicating whether the previous chunk is in use (P), whether the chunk is mmap‑allocated (M), and whether it belongs to a non‑main arena (A)

fd and bk : forward and backward pointers used when the chunk is free

Chunks are organized into several bins :

fast bins : store very small chunks (size ≤ 64 bytes) in singly‑linked lists; allocation/deallocation occurs at the head for speed.

unsorted bin : a buffer for chunks of any size that have just been freed; the allocator first tries to reuse chunks from here.

small bins : manage chunks < 512 B, each bin holds chunks of a specific size and is a doubly‑linked circular list.

large bins : manage chunks ≥ 512 B, sorted by size (descending) and then by time.

2.2 Allocation Process (malloc)

The allocation flow can be summarised as:

Lock the arena.

Calculate the required chunk size.

If size < max_fast , search fast bins; otherwise continue.

If size < 512 B, search small bins.

If not found, traverse fast bins, coalesce adjacent chunks, and move them to the unsorted bin.

Search the unsorted bin; if a suitable chunk is found, split it and allocate.

If still not found, search large bins (reverse order) for a big enough chunk, split, and place the remainder into the unsorted bin.

If no suitable chunk exists, try the top chunk . If the top chunk is too small, request more memory from the OS (via brk() for the main arena or mmap() for non‑main arenas).

2.3 Free Process (free)

The deallocation flow is:

Lock the arena.

If the pointer is NULL, return.

If the chunk was mmap‑allocated, call munmap() .

If the chunk is adjacent to the top chunk, merge with the top chunk.

If the chunk size > max_fast , place it into the unsorted bin and attempt consolidation.

If the chunk size ≤ max_fast , place it into the appropriate fast bin; if merging creates a large chunk, move it to the unsorted bin.

Periodically, fast bins are coalesced and large chunks may be returned to the OS when the top chunk exceeds the shrink threshold (default 128 KB).

3. Advantages and Disadvantages

ptmalloc satisfies the needs of most large‑scale projects and its design has influenced later allocators. However, its performance is generally inferior to specialised allocators like jemalloc and tcmalloc.

Future articles will explore high‑performance allocators such as jemalloc and tcmalloc.

References

https://sourceware.org/glibc/wiki/MallocInternals

https://sploitfun.wordpress.com/tag/ptmalloc/

https://www.cnblogs.com/biterror/p/691323