NVML

NVML, the NVM Library (Non-Volatile Memory Library), is an open-source collection of libraries and tools created by Intel to make it practical to write software for byte-addressable persistent memory. Rather than a conventional general-purpose programming language, NVML is a set of C libraries – with C++ bindings – that layer a higher-level, transactional programming model on top of the raw memory-mapped access that operating systems expose for persistent memory. In December 2017 the project was renamed the Persistent Memory Development Kit (PMDK), the name it has carried ever since. NVML occupies an unusual niche in the encyclopedia of programming systems: it is a systems library whose central abstraction – the transaction – lets programmers describe what should remain consistent across a crash rather than hand-coding the imperative cache-flushing and recovery logic themselves.

History & Origins

Background and Motivation

For decades the memory hierarchy presented programmers with a hard divide: fast but volatile DRAM, accessed with ordinary load/store instructions, and slow but durable block storage (disks and SSDs), accessed through a file or block API. Persistent memory – non-volatile media that sits on the memory bus and is addressed at byte granularity like DRAM – collapsed that divide. It promised data that survives power loss while still being reachable with a CPU load or store, with no block layer in the path.

That promise created a new and subtle problem. When an application maps persistent memory into its address space, the operating system gives it only “a very raw form of access,” in the words of the project’s own 2014 overview. Standard tools such as malloc() “don’t comprehend the idea of persistence.” A simple store instruction does not guarantee that data has actually reached the persistence domain; it may still sit in CPU caches or write buffers. If power is lost at the wrong moment, in-memory data structures can be left half-updated and corrupt. Programmers needed a disciplined way to allocate persistent memory, to flush and order writes correctly, and – above all – to update structures atomically so that a crash never leaves them inconsistent.

The NVM Library (2014)

Intel responded by starting the NVM Library as an open-source project in 2014, hosted on GitHub and documented at the newly created pmem.io website. The team’s initial focus was a Linux library that would provide the APIs that persistent-memory programming needed – memory allocation, transactions, and related facilities – on top of the operating system’s memory-mapped file interface. The project was deliberately named the NVM Library rather than the PMEM Library because, as its authors noted, the code “will work on top of any non-volatile memory, not just persistent memory.”

From the outset NVML was not one library but several, each targeting a different use case. The early set included:

• libpmem – low-level persistent-memory support (flushing, ordering, copying)
• libpmemobj – a transactional object store with persistent memory allocation
• libpmemlog – an append-only persistent log
• libpmemblk – arrays of fixed-size blocks with atomic updates
• libvmem and libvmmalloc – volatile memory allocators backed by memory-mapped files

NVML implemented the SNIA NVM Programming Model, a vendor-neutral specification developed by roughly fifty companies under the Storage Networking Industry Association to standardize how software discovers and uses non-volatile memory. NVML became one of the most prominent production-quality implementations of that model’s “persistent memory” (direct-access) mode.

From NVML to PMDK (2017)

As the project matured, its single-library name became misleading. By late 2017 the project encompassed around ten libraries plus tooling and language support spanning C, C++, and bindings for other languages. On December 11, 2017, the team announced that NVML was being renamed the Persistent Memory Development Kit (PMDK) – a name that better described a kit of components rather than one monolithic library. The libraries themselves kept their libpmem* names; only the umbrella project was rebranded.

Hardware Arrives and the Landscape Shifts (2019-2022)

For its first several years NVML/PMDK ran ahead of widely available hardware, used mostly with emulated persistent memory or early devices. That changed when Intel Optane DC Persistent Memory began shipping around April 2019, putting byte-addressable persistent memory modules into mainstream servers and giving PMDK a large real-world target.

The momentum did not last. In 2022 Intel announced it was winding down its Optane business. In a November 2022 statement, Intel said it would correspondingly scale back new feature development on PMDK, commit to critical security and bug fixes while Optane products remained in their support window, and encourage community members and collaborators to take on maintainer roles for the long term. The open-source code and the pmem.io documentation would remain available.

In the years that followed, the project pruned itself. The remote-persistent-memory library librpmem was deprecated and removed (its users pointed toward the newer librpma RDMA library), and libpmemblk and libpmemlog were retired after the 1.13.x line. With PMDK 2.0.0 in August 2023, the project removed non-Linux support from its build paths, refocusing on Linux. The most recent release, PMDK 2.1.1, appeared in February 2025. In November 2025 the original pmem/pmdk GitHub repository was archived (made read-only), with ongoing maintenance reportedly moving to a fork stewarded by the DAOS project.

Design Philosophy

NVML was shaped by a few clear convictions about how persistent-memory programming should feel.

Make Persistence a First-Class Concern

The library’s reason for existing is that ordinary memory tools ignore durability. NVML makes persistence explicit: persistent data lives inside a pool (a memory-mapped file on a persistent-memory-aware filesystem), persistent allocations are tracked so they survive restarts, and the library provides the flush-and-fence primitives needed to push data into the persistence domain in the correct order.

Declarative Crash Consistency Through Transactions

NVML’s most distinctive idea is that programmers should not hand-roll crash-recovery logic. With libpmemobj, a developer wraps a set of updates in a transaction and declares which memory ranges the transaction will modify. The library then guarantees that, after any crash, the persistent state reflects either all of the transaction’s changes or none of them. The programmer describes the consistency requirement declaratively; the library supplies the undo logging, ordering, and recovery imperatively under the hood. This is the sense in which NVML brings a declarative model to an otherwise low-level systems domain.

Stay Close to the Metal, but Portable

Because NVML is implemented in C and exposes the underlying memory directly, it adds little overhead between the application and the hardware. At the same time, by building on the OS’s memory-mapped-file interface and the SNIA model, it aimed to run anywhere the operating system exposed the necessary persistent-memory interfaces – historically both Linux and (during the 1.x era) Microsoft Windows.

Key Features

Persistent Object Store (libpmemobj)

The flagship library, libpmemobj, provides a transactional object store: persistent memory allocation, atomic transactions, typed persistent pointers, and helpers for building persistent data structures. A simplified C example of a transactional update looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

#include <libpmemobj.h>

struct account {
    uint64_t balance;
};

POBJ_LAYOUT_BEGIN(bank);
POBJ_LAYOUT_ROOT(bank, struct account);
POBJ_LAYOUT_END(bank);

void deposit(PMEMobjpool *pop, uint64_t amount)
{
    TOID(struct account) root = POBJ_ROOT(pop, struct account);

    /* Either both the snapshot and the update survive a crash, or neither does */
    TX_BEGIN(pop) {
        TX_ADD(root);                       /* declare what the transaction will modify */
        D_RW(root)->balance += amount;      /* the actual update */
    } TX_END
}

The TX_BEGIN/TX_END block expresses the consistency requirement declaratively, while TX_ADD tells the library which memory to protect with undo logging.

Low-Level Primitives (libpmem and libpmem2)

For developers who want to implement their own persistence algorithms, libpmem offers the essential building blocks – detecting whether a mapping is true persistent memory, and flushing or copying data with correct ordering. The later libpmem2 redesigned this interface to be “more universal and platform-agnostic” for custom algorithms.

Specialized Libraries

The kit historically bundled purpose-built libraries – an append-only log (libpmemlog), fixed-size atomic block arrays (libpmemblk), volatile allocators backed by mmap (libvmem, libvmmalloc), offline pool management and diagnostics (libpmempool), and remote persistent memory over RDMA (librpmem). Several of these have since been retired as the project narrowed its focus.

C++ Bindings

On top of libpmemobj, the project provides C++ bindings (libpmemobj-cpp) that bring transactions, persistent pointers, and persistent-memory-aware container types to C++ programmers, requiring a C++11-compliant compiler (with one feature needing C++17).

Evolution

NVML’s history falls into several distinct phases:

• 2014-2017 (NVML): Founding of the project, creation of the core libpmem* libraries, and implementation of the SNIA NVM Programming Model. Hardware was scarce, so most use was on emulated persistent memory.
• 2017-2019 (Rename and hardware): The project becomes PMDK (December 2017), and Intel Optane DC Persistent Memory ships around 2019, giving the libraries real hardware and a wave of adoption in databases and storage systems.
• 2020-2022 (Modernization): Introduction of libpmem2 and continued growth of the C++ bindings, alongside steady releases through the 1.x line.
• 2022-present (Consolidation): Intel’s wind-down of Optane (2022) reduces corporate investment; the project sheds libraries, drops non-Linux support in PMDK 2.0 (2023), and transitions toward a leaner, community-stewarded, Linux-focused codebase.

Current Relevance

PMDK – NVML’s direct continuation – remains available as open source, with documentation preserved at pmem.io; its latest release was 2.1.1 in February 2025. Intel’s original pmem/pmdk GitHub repository was archived (made read-only) in November 2025, and ongoing maintenance has reportedly shifted to a fork stewarded by the DAOS project. Its trajectory is, however, closely tied to the fate of the persistent-memory hardware it was built for. With Intel having exited the Optane business, the most visible commercial driver for byte-addressable persistent memory has receded, and active investment in the libraries has shifted from a single vendor toward the community and the projects that still depend on them, most notably the DAOS storage system.

The ideas NVML pioneered have outlived the specific hardware moment. Its transactional, crash-consistent programming model, its careful treatment of cache flushing and ordering, and its role in popularizing the SNIA NVM Programming Model continue to inform how operating systems, databases, and storage engines think about durability on memory-class media – including emerging Compute Express Link (CXL) memory.

Why It Matters

NVML’s significance is less about syntax than about a programming model for a new tier of the memory hierarchy:

1. It defined how to program persistent memory. NVML gave a generation of systems programmers their first practical, well-documented APIs for byte-addressable persistent memory, turning a raw and dangerous form of access into something with allocation, typing, and transactions.
2. It made crash consistency declarative. By letting programmers declare transactional regions and protected ranges instead of hand-writing undo logs and recovery code, NVML brought a degree of declarative safety to one of the most error-prone corners of systems programming.
3. It anchored an industry standard. As a prominent implementation of the SNIA NVM Programming Model, NVML helped a vendor-neutral specification become concrete and usable, encouraging interoperability across the persistent-memory ecosystem.
4. It outlived its rebrand and its hardware. Renamed to PMDK and now maintained largely by its community, the project endures as both a working toolkit and a reference design whose lessons carry forward into CXL and other memory-semantic technologies.

NVML is a reminder that some of the most consequential “languages” in computing are not general-purpose languages at all, but focused libraries that introduce a new abstraction – here, durable, transactional, byte-addressable memory – and teach an entire industry how to use it safely.