Understanding and optimizing persistent memory allocation

Abstract

The proliferation of fast, dense, byte-addressable nonvolatile memory suggests that data might be kept in pointer-rich "in-memory" format across program runs and even process and system crashes. For full generality, such data requires dynamic memory allocation, and while the allocator could in principle be "rolled into" each data structure, it is desirable to make it a separate abstraction.Toward this end, we introduce recoverability, a correctness criterion for persistent allocators, together with a nonblocking allocator, Ralloc, that satisfies this criterion. Ralloc is based on the LRMalloc of Leite and Rocha, with three key innovations. First, we persist just enough information during normal operation to permit correct reconstruction of the heap after a fullsystem crash. Our reconstruction mechanism performs garbage collection (GC) to identify and remedy any failure-induced memory leaks. Second, we introduce the notion of filter functions, which identify the locations of pointers within persistent blocks to mitigate the limitations of conservative GC. Third, to allow persistent regions to be mapped at an arbitrary address, we employ position-independent (offset-based) pointers for both data and metadata.Experiments show Ralloc to be performance-competitive with both Makalu, the state-of-theart lock-based persistent allocator, and such transient allocators as LRMalloc and JEMalloc. In particular, reliance on GC and offline metadata reconstruction allows Ralloc to pay almost nothing for persistence during normal operation.

NVAlloc: rethinking heap metadata management in persistent memory allocators

“…For allocating small objects, slabs are widely used in the existing allocators including volatile memory allocators (e.g., jemalloc-5.2.1 [17] and tcmalloc-2.9.1 [18]) and persistent memory allocators (e.g., Makalu [3], Ralloc [4], nvm_malloc [37], and PMDK-1.11 [11]). Slabs are segregated based on size classes.…”

“…We use an offset-based pointer representation to allow persistent structures to be mapped at different virtual addresses after failure recovery. The same technique has been used in previous projects [4,6,9]. The nvalloc_free_from() returns a block or an extent specified by 𝑎𝑑𝑑𝑟𝑒𝑠𝑠 to the persistent memory heap.…”

“…Many allocators have been designed for persistent memory [3,4,15,30,31,37]. They need to manage persistent heaps via various types of metadata (e.g., object bitmaps, slab structures, extent headers, and write-ahead logs ) for efficiently serving memory allocation and deallocation.…”

Garbage collection and data recovery for N2DB

“…NVM-aware allocators need to ensure the atomicity and durability of allocations and reclamation. In the wake of a crash, the allocator can bring its metadata to a state in which all and only the in-use blocks are allocated [22] .…”

“…NVM-aware allocator: Bhandari et al [12] and Cai et al [22] proposed fine-grained log-freedom allocators that provide a malloc/free interface similar to the counterparts for DRAM. These allocators use a postcrash GC to reclaim leaked memory.…”