NV-Heaps

Coburn, Joel; Caulfield, Adrian M.; Akel, Ameen; Grupp, Laura M.; Gupta, Rajesh K.; Jhala, Ranjit; Swanson, Steven

doi:10.1145/1950365.1950380

Cited by 394 publications

(31 citation statements)

References 43 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…A number of recent programming models for byte-addressed non-volatile memory such as Mnemosyne [Volos et al 2011], NV-Heaps [Coburn et al 2011], and others [Bhandari et al 2016;Chakrabarti et al 2014] are based on managed persistent regions which are very similar to those used in Boost for volatile memory. The main focus of these works is guaranteeing failure atomicity of shared persistent data structures.…”

Section: Shared and Managed Data Structuresmentioning

confidence: 99%

“…In such situations, direct sharing of objects via managed memory techniques effectively enables faster inter-process communication. Such memory management techniques have also received recent attention from non-volatile memory programming models centered around persistent in-memory data-structures [Bhandari et al 2016;Chakrabarti et al 2014;Coburn et al 2011;Volos et al 2011]. This renewed interest is in part due to the fact that load-store domains will become very large, sharing will be much more common, and long latencies will be exposed [Asanovic 2014;Bresniker et al 2015;Narayanan and Hodson 2012], therefore efficient object sharing will be critical for application performance.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

SAVI objects: sharing and virtuality incorporated

Hajj

Jablin

Milojičić

et al. 2017

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Direct sharing and storing of memory objects allows high-performance and low-overhead collaboration between parallel processes or application workflows with loosely coupled programs. However, sharing of objects is hindered by the inability to use subtype polymorphism which is common in object-oriented programming languages. That is because implementations of subtype polymorphism in modern compilers rely on using virtual tables stored at process-specific locations, which makes objects unusable in processes other than the creating process.In this paper, we present SAVI Objects, objects with Sharing and Virtuality Incorporated. SAVI Objects support subtype polymorphism but can still be shared across processes and stored in persistent data structures. We propose two different techniques to implement SAVI Objects and evaluate the tradeoffs between them. The first technique is virtual table duplication which adheres to the virtual-table-based implementation of subtype polymorphism, but duplicates virtual tables for shared objects to fixed memory addresses associated with each shared memory region. The second technique is hashing-based dynamic dispatch which re-implements subtype polymorphism using hashing-based look-ups to a global virtual table.Our results show that SAVI Objects enable direct sharing and storing of memory objects that use subtype polymorphism by adding modest overhead costs to object construction and dynamic dispatch time. SAVI Objects thus enable faster inter-process communication, improving the overall performance of production applications that share polymorphic objects.

show abstract

Section: Shared and Managed Data Structuresmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

SAVI objects: sharing and virtuality incorporated

Hajj

Jablin

Milojičić

et al. 2017

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

show abstract

“…Usually, persistent heaps [19], [20] deploy a mmap sys-tem call to allocate the user buffer from PM. When servicing the mmap system call in the file system, we managed which process requested the mapping and the mapping information in a list (zcl mmap list).…”

Section: Methodsmentioning

confidence: 99%

Copy-on-Write with Adaptive Differential Logging for Persistent Memory

Hwang

Won

2019

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

File systems based on persistent memory deploy Copyon-Write (COW) or logging to guarantee data consistency. However, COW has a write amplification problem and logging has a double write problem. Both COW and logging increase write traffic on persistent memory. In this work, we present adaptive differential logging and zero-copy logging for persistent memory. Adaptive differential logging applies COW or logging selectively to each block. If the updated size of a block is smaller than or equal to half of the block size, we apply logging to the block. If the updated size of a block is larger than half of the block size, we apply COW to the block. Zero-copy logging treats an user buffer on persistent memory as a redo log. Zero-copy logging does not incur any additional data copy. We implement adaptive differential logging and zero-copy logging on both NOVA and PMFS file systems. Our measurement on real workloads shows that adaptive differential logging and zero-copy logging get 150.6% and 149.2% performance improvement over COW, respectively.

show abstract

“…Relaxing the ordering of updates and persist actions to different locations may expose a re-ordering to code resuming execution after a failure and persistency models describe which of these re-orderings are valid. Other, earlier work developed mechanisms for managing data structures in non-volatile memory, and for building consistent memory and file systems out of byte-addressable non-volatile memory [Coburn et al 2011;Condit et al 2009;Doshi and Varman 2012;Dulloor et al 2014;Moraru et al 2013;Narayanan and Hodson 2012;Venkataraman et al 2011;Volos et al 2011]. Alpaca relates to these efforts because both aim to keep non-volatile memory consistent across power failures.…”

Section: Memory Persistency and Non-volatile Memory Systemsmentioning

confidence: 99%

Alpaca: intermittent execution without checkpoints

Maeng

Colin

Lucia

2017

Proc. ACM Program. Lang.

192

261

View full text Add to dashboard Cite

The emergence of energy harvesting devices creates the potential for batteryless sensing and computing devices. Such devices operate only intermittently, as energy is available, presenting a number of challenges for software developers. Programmers face a complex design space requiring reasoning about energy, memory consistency, and forward progress. This paper introduces Alpaca, a low-overhead programming model for intermittent computing on energy-harvesting devices. Alpaca programs are composed of a sequence of userdefined tasks. The Alpaca runtime preserves execution progress at the granularity of a task. The key insight in Alpaca is the privatization of data shared between tasks. Updates of shared values in a task are privatized and only committed to main memory on successful execution of the task, ensuring that data remain consistent despite power failures. Alpaca provides a familiar programming interface and a highly efficient runtime model. We also present an alternate version of Alpaca, Alpaca-undo, that uses undo-logging and rollback instead of privatization and commit. We implemented a prototype of both versions of Alpaca as an extension to C with an LLVM compiler pass. We evaluated Alpaca, and directly compared to three systems from prior work. Alpaca consistently improves performance compared to the previous systems, by up to 23.8x, while also improving memory footprint in many cases, by up to 17.6x. C1:A program must preserve progress despite losing volatile state on power failures. C2: A program must have a consistent view of its state across volatile and non-volatile memory. C3: A program must respect atomicity constraints (e.g., sampling related sensors together).G1: Applications should place as few restrictions on the hardware as possible.G2: Applications should be tunable at design time to use the energy storage capacity efficiently. G3: Applications should minimize runtime overhead and memory footprint. Recent work made progress toward several of these goals, but necessarily compromised on others. This paper develops Alpaca 1 , a programming and execution model that allows software to execute intermittently. Like state-of-the-art systems, Alpaca preserves progress despite power failures (C1) and ensures memory consistency (C2). Alpaca uses a static task model that can adhere to programmer-provided atomicity constraints and energy availability (G2, C3). Memory updates made by an Alpaca task only commits atomically when the task completes. By discarding memory updates on power failure, Alpaca can restart a task with negligible cost, without checkpointing the volatile state as in prior work [Lucia and Ransford 2015;; Van Der Woude and Hicks 2016] (G3). Unlike prior work that requires the entire memory to be non-volatile [Van Der Woude and Hicks 2016], Alpaca can leverage both volatile and non-volatile memory (G1). We present two different versions of Alpaca with different design choices. Alpaca's design differences, relative to state-of-the-art systems, translate into performance gains of 4-5.2x o...

show abstract

NV-Heaps

Cited by 394 publications

References 43 publications

SAVI objects: sharing and virtuality incorporated

SAVI objects: sharing and virtuality incorporated

Copy-on-Write with Adaptive Differential Logging for Persistent Memory

Alpaca: intermittent execution without checkpoints

Contact Info

Product

Resources

About