Skip to content

Prevent memory bloat caused by a jemalloc quirk

Since version 5.0.0, decay-based purging is the only available dirty page cleanup mechanism in jemalloc. It relies on so-called tickers, which are simple data structures used for ensuring that certain actions are taken "once every N times". Ticker data (state) is stored in a thread-specific data structure called tsd in jemalloc parlance. Ticks are triggered when extents are allocated and deallocated. Once every 1000 ticks, jemalloc attempts to release some of the dirty pages hanging around (if any). This allows memory use to be kept in check over time.

This dirty page cleanup mechanism has a quirk. If the first allocator-related action for a given thread is a free(), a minimally-initialized tsd is set up which does not include ticker data. When that thread subsequently calls *alloc(), the tsd transitions to its nominal state, but due to a certain flag being set during minimal tsd initialization, ticker data remains unallocated. This prevents decay-based dirty page purging from working, effectively enabling memory exhaustion over time. [1]

The quirk described above has been addressed (by moving ticker state to a different structure) in jemalloc's development branch [2], but not in any numbered jemalloc version released to date (the latest one being 5.2.1 as of this writing).

Work around the problem by ensuring that every thread spawned by isc_thread_create() starts with an malloc() call. Avoid immediately calling free() for the dummy allocation to prevent an optimizing compiler from stripping away the malloc() + free() pair altogether.

[1] https://github.com/jemalloc/jemalloc/issues/2251

[2] https://github.com/jemalloc/jemalloc/commit/c259323ab3082324100c708109dbfff660d0f4b8

Closes #3287 (closed)

Edited by Michał Kępień

Merge request reports