Object-oriented recovery for non-volatile memory

Abstract

New non-volatile memory (NVM) technologies enable direct, durable storage of data in an application's heap. Durable, randomly accessible memory facilitates the construction of applications that do not lose data at system shutdown or power failure. Existing NVM programming frameworks provide mechanisms to consistently capture a running application's state. They do not, however, fully support object-oriented languages or ensure that the persistent heap is consistent with the environment when the application is restarted. In this paper, we propose a new NVM language extension and runtime system that supports objectoriented NVM programming and avoids the pitfalls of prior approaches. At the heart of our technique is object reconstruction, which transparently restores and reconstructs a persistent object's state during program restart. It is implemented in NVMReconstruction, a Clang/LLVM extension and runtime library that provides: (i) transient fields in persistent objects, (ii) support for virtual functions and function pointers, (iii) direct representation of persistent pointers as virtual addresses, and (iv) type-specific reconstruction of a persistent object during program restart. In addition, NVMReconstruction supports updating an application's code, even if this causes objects to expand, by providing object migration. NVMReconstruction also can compact the persistent heap to reduce fragmentation. In experiments, we demonstrate the versatility and usability of object reconstruction and its low runtime performance cost.

Verifying Correctness of Persistent Concurrent Data Structures

“…There are numerous approaches to proving (standard) linearizability of concurrent data structures (e.g., [27,1,24]; see [9] for an overview), including specialisations to cope with weak memory models (e.g., [25,2,26,5,22,7]). The recent development of NVM has been accompanied by persistent versions of well-known concurrent constructs, including concurrent objects [11,3], synchronisation primitives [13,21] and transactional memory [16]. This paper has focussed on a persistent queue [11], against the recently developed notion of durable linearizability [14].…”

“…The final (and most complex) of these steps, which establishes that the implementation refines the operational model, is fully mechanised in the KIV theorem prover [10]. It is important to note that the operational model is generic and for any particular verification one needs therefore just to establish step (3) in order to show that a particular algorithm is durable linearizable.…”

Finding and Fixing Performance Pathologies in Persistent Memory Software Stacks

“…First, Redis represents and stores different objects with different encodings and formats, and P-Redis has to be able to interpret and handle the various types of objects properly. Second, Redis stores virtual addresses in the hashtable, and P-Redis needs to either adjust the addresses upon restart if the virtual address of the mmap'd hashtable file has changed, or change the internal hashtable implementation to use offset instead of absolute addresses [16]. Neither option is satisfying, and we choose the former solution for simplicity.…”

Vorpal

“…[17,18,37]. Other work has explored systems software, such as transactional memory-type abstractions [7,16,27,45], file systems [47], and data structures [8,13,33,44]. Vector Clocks.…”