Pith. sign in

REVIEW 3 major objections 6 minor 49 references

MOD: Minimally Ordered Durable Datastructures for Persistent Memory

T0 review · 3 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper proposes MOD datastructures that make failure-atomic persistent-memory updates cost one ordering point per operation, outperforming general-purpose transactions on real hardware.

desk verdict MOD gives the persistent-memory community a genuinely useful middle ground between hand-crafted datastructures and PM-STM, measured on real Optane hardware, but the failure-atomicity story has a load-bearing gap around the allocator's own crash consistency. read the letter →

arxiv 1908.11850 v1 pith:GMTJX653 submitted 2019-08-21 cs.DC cs.PL

Swapnil Haria , Mark D. Hill , Michael M. Swift This is my paper · ORCID
classification cs.DCcs.PL
keywords persistentmemorynon-volatilecrashconsistencyfailure-atomicitydurabledatastructuresfunctionalshadowingstructuralsharingorderingpoints
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

MOD aims to be the middle ground between hand-tuned durable datastructures and general-purpose persistent-memory transactions: a C++ library of map, set, stack, queue, and vector that hides crash-consistency details from programmers. The paper's central claim is that a failure-atomic update can be made durable with one ordering point if the update is written out of place and only the final pointer swap is ordered. This matters because current transactional approaches spend most of their execution time flushing and logging, and the paper identifies ordering constraints, not write volume, as the main bottleneck. On real persistent-memory hardware, MOD reports roughly 40 percent speedups on pointer-based containers and 38 percent on applications over the state-of-the-art transactional baseline. If the design holds up, recoverable applications become both easier to write and faster to run.

What carries the argument

Functional Shadowing: each update writes a new version entirely out of place, flushing dirty cachelines with unordered cacheline-flush instructions and no fences; a single ordering point then makes the shadow durable before an 8-byte atomic pointer write swaps in the new root. Structural sharing, borrowed from purely functional datastructures, keeps the shadow small by reusing untouched sub-trees. The Commit step comes in three forms—single, siblings, and unrelated—so the common cases keep exactly one ordering point per failure-atomic section.

What would settle it

A fault-injection campaign that crashes a MOD workload at every instruction boundary during an update and then runs recovery, marking every reachable node, would settle the central claim: if recovery frees any reachable node or retains any unreachable block, failure-atomicity fails.

Watch

Extended reading notes

Core claim

The central claim is that the dominant cost of failure-atomic updates to persistent memory is ordering, not write volume, and that this cost can be reduced to a single fence per operation. MOD datastructures implement every update as an out-of-place write: a new "shadow" version of the datastructure is built from freshly allocated nodes, reusing untouched sub-trees of the old version through structural sharing. Because the shadow shares no persistent pointers with the old version, its dirty cachelines can be flushed in any order with no logging, and one ordering point before an atomic 8-byte pointer swap makes the new version durable and atomically replaces the old. The paper shows on real persistent-memory hardware that this design improves map, set, stack, and queue microbenchmarks by 40 percent and application benchmarks by 38 percent relative to the state-of-the-art transactional baseline, while vector workloads are slower. It also presents a recipe for turning existing purely functional datastructures into MOD datastructures and a composition interface that commits multi-structure updates with one ordering point in the common cases.

Load-bearing premise

Failure-atomicity holds only if the persistent allocator's internal bookkeeping survives crashes consistently and its recovery pass frees exactly the unreachable blocks — an assumption the paper borrows from an off-the-shelf allocator without analyzing its crash behavior.

Editorial extensions

If this is right

  • Failure recovery no longer needs log replay: after a crash the latest committed root pointer still identifies a consistent durable version, and uncommitted shadows are garbage.
  • Pointer-based containers gain roughly 40 percent over the transactional baseline on current hardware, and whole applications gain about 36-38 percent.
  • A single ordering point per operation suffices for one datastructure or for multiple datastructures under a common parent; only unrelated datastructures need a short transaction.
  • Any existing purely functional datastructure can be converted into a recoverable MOD datastructure by allocating its state in persistent memory and flushing modified cachelines without ordering.
  • The benefit does not extend to array-like containers: MOD's vector is slower because the tree-based functional layout sacrifices dense memory.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A fault-injection crash study, which the paper does not report, is the natural next test: crash at different points inside allocation and commit and check that no reachable node is reclaimed and no unreachable block survives.
  • MOD's advantage should widen on hardware with higher flush latency and narrow if future hardware makes ordering points cheap; the paper's Amdahl-style latency model suggests the scaling curve.
  • Trying the recipe on other functional collections, such as priority queues, tries, or ropes, would show how far the one-fence design generalizes, with the vector slowdown warning that dense layouts may not fit.
  • The volatile reference-count reset assumes single-parent sharing in the surviving version; datastructures that share a subtree among multiple parents in one version would need a different reclamation rule.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper proposes Minimally Ordered Durable (MOD) datastructures, a C++ library of persistent datastructures (map, set, stack, queue, vector) that use functional shadowing with structural sharing to provide failure-atomic updates while minimizing ordering points. The design has a Basic interface for single updates and a Composition interface for multi-update FASEs, with one sfence per FASE in the common case. The authors evaluate on real Intel Optane hardware against PMDK v1.5, reporting average speedups of 43% for pointer-based microbenchmarks and 36% for application benchmarks, while honestly disclosing vector slowdowns. The paper also contributes a recipe for porting existing functional datastructures, a recovery scheme based on reference counting and a recovery garbage collector, an automated testing framework, and an analytical model for flush latency.

Significance. If the design is correct, MOD offers a practical middle ground between hand-crafted persistent datastructures and general-purpose PM-STM, and the real-hardware evaluation demonstrates that reducing ordering constraints is a effective strategy. The paper also provides a credible recipe for constructing additional recoverable datastructures and releases an implementation, both of which are useful to the community. However, the central failure-atomicity claim depends on an unverified assumption about the crash consistency of the underlying allocator, and the correctness argument contains an ambiguity about where reference counts are stored. These issues must be resolved before the headline claims can be accepted.

major comments (3)
  1. [4.2, 5.3] The failure-atomicity claim of the abstract and Section 1 depends on the persistent heap remaining recoverable after a crash, but the paper uses the off-the-shelf nvm_malloc allocator without analyzing its crash behavior. Section 5.3 states that recovery garbage collection can reclaim 'any unmarked data remaining in the persistent heap,' but this is only sound if nvm_malloc's block headers, free lists, and allocation state are themselves crash-consistent. A crash during a malloc/free can leave metadata inconsistent, making the heap untraversable and invalidating the mark-sweep recovery. Please add a fault-injection test of the allocator, a crash-consistency argument, or a modification of the allocator to make its metadata failure-atomic; as written, the central guarantee is unverified.
  2. [5.2, 5.3, 5.4] There is an internal inconsistency in the correctness argument. Section 5.2 and Section 5.4 require that all PM writes outside Commit be restricted to newly allocated data, but Section 5.3 describes reference counting in which 'we increment reference counts of nodes that are reused on an update operation.' If these reference counts are stored in PM nodes, an update writes to pre-existing persistent data, violating the invariant. If reference counts are kept in volatile memory, the paper should state this explicitly and explain how recovery reconstructs them; if they are in PM but are exempt from flushing and reset on crash, the invariant in Section 5.4 needs to be amended to exclude refcount fields. Please clarify and make the testing framework consistent with the storage location of reference counts.
  3. [5.4, 6] The paper's verification of failure atomicity is limited to trace-based invariant checking on successful runs; there is no crash-injection test that powers off the machine mid-FASE and checks that recovery restores a consistent version. Since the central claim concerns behavior on crashes, please add such a test (at least a kill -9 or power-loss simulation) for all datastructures and for the allocator, and report the recovery outcomes.
minor comments (6)
  1. [Abstract, Section 1] The abstract reports 40%/38% microbenchmark/application speedups, while Section 1 reports 43%/36%; please reconcile these numbers and the 'hurts vector by 122%' phrasing with Figure 9.
  2. [Table 3] Table 3 reports that MOD vector consumes 131x memory at 2M elements versus 1M, which is surprising for a structural-sharing implementation; please explain or correct this value.
  3. [Section 3] The analytical model in Section 3 (listed as a contribution) is an Amdahl's law curve fit with a fitted parallel fraction f=0.82 rather than a mechanistic model; the text already acknowledges the hardware is a black box, so consider describing this as a descriptive fit, not an analytical model.
  4. [Section 6.1] Section 6.1 should report the number of runs and variance for the timing experiments; without repeated runs it is unclear whether the 43%/36% differences are within noise.
  5. [References] Reference [45] contains typos ('Stroage' should be 'Storage') and the venue is 'FAST' rather than 'FASE'.
  6. [Section 1] The introduction says the implementation is released, but no repository URL is provided; please include one.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: MOD's performance claims are direct measurements and the only named analytical model is explicitly a fit, not an independent prediction.

full rationale

The central claims (one ordering point, failure-atomic updates, 40%/38% speedups) are supported by design arguments and by direct empirical comparison with PMDK v1.5 on Optane hardware, not by a derivation from the paper's own outputs. The Functional Shadowing technique is adapted from shadow paging and functional datastructures with cited external foundations, and the correctness argument in Section 5.2 is a structural invariant rather than a self-referential assumption. The one candidate for circularity, the Section 3 'Analytical Model of Flush Latencies', is explicitly labeled 'an Amdahl's law fit using the Karp-Flatt metric' with f=0.82 and an 18% serial component; the paper does not use that fitted curve to predict any benchmark result or to justify the MOD performance numbers, which are measured. The recovery/garbage-collection discussion assumes crash-consistent allocator metadata from nvm_malloc without analysis, but that is a correctness risk, not a case of a derivation reducing to its own inputs. Self-citations such as WHISPER [34] appear only as workload/background sources and are not load-bearing for the MOD design or its measured speedups. Overall, no circular step is present.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

Everything the central claim rests on: x86 flush/fence semantics; a persistent allocator that stays consistent through a crash; tree datastructures with single-parent nodes in one version; and engineering-sample Optane behavior being representative. The only fitted number in the paper is the Amdahl f=0.82 flush-latency curve fit. No invented entities.

free parameters (1)
  • Amdahl parallel fraction f = 0.82
    Fitted via Karp-Flatt metric to the observed flush-latency curve in Figure 4. The paper calls this an analytical model but provides no mechanism for the 18% serial component.
assumptions (4)
  • domain assumption clwb and sfence semantics on x86 match the order model described: clwb commits instantly and flushes in the background, sfence waits for in-flight flushes, and 8-byte aligned stores are atomic.
    Used throughout the design (Sections 2.1, 5.1) to argue that one fence plus one pointer swap is sufficient for failure atomicity.
  • domain assumption A crash can leave allocator state and persistent heaps in a state where post-crash mark-sweep garbage collection from datastructure roots is sound and complete.
    Section 5.3 relies on this for memory reclamation of incomplete FASEs and old versions; the paper does not analyze nvm_malloc's crash consistency.
  • domain assumption In a single surviving version of a MOD datastructure, every reachable internal node has exactly one parent, so resetting all reference counts to 1 during recovery is correct.
    Section 5.3 resets refcounts to 1 on recovery; this requires the data structures (CHAMP, RRB) to be trees without multi-parent sharing within one version.
  • domain assumption The measured behavior of engineering-sample Optane DCPMM (flush concurrency curve) is representative of production persistent memory.
    All results are from one machine with engineering samples; see Table 1 and Section 3.

how reviews work

0 comments
Cite this review

Pith. "Pith review of MOD: Minimally Ordered Durable Datastructures for Persistent Memory." pith.science (2026). https://pith.science/paper/GMTJX653

@misc{pith2026190811850,
  author       = {Pith},
  title        = {Pith review of: MOD: Minimally Ordered Durable Datastructures for Persistent Memory},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GMTJX653}},
  note         = {Machine review of arXiv:1908.11850}
}
read the original abstract

Persistent Memory (PM) makes possible recoverable applications that can preserve application progress across system reboots and power failures. Actual recoverability requires careful ordering of cacheline flushes, currently done in two extreme ways. On one hand, expert programmers have reasoned deeply about consistency and durability to create applications centered on a single custom-crafted durable datastructure. On the other hand, less-expert programmers have used software transaction memory (STM) to make atomic one or more updates, albeit at a significant performance cost due largely to ordered log updates. In this work, we propose the middle ground of composable persistent datastructures called Minimally Ordered Durable (MOD) datastructures. MOD is a C++ library of several datastructures---currently, map, set, stack, queue and vector--- that often perform better than STM and yet are relatively easy to use. They allow multiple updates to one or more datastructures to be atomic with respect to failure. Moreover, we provide a recipe to create more recoverable datastructures. MOD is motivated by our analysis of real Intel Optane PM hardware showing that allowing unordered, overlapping flushes significantly improves performance. MOD reduces ordering by adapting existing techniques for out-of-place updates (like shadow paging) with space-reducing structural sharing (from functional programming). MOD exposes a Basic interface for single updates and a Composition interface for atomically performing multiple updates. Relative to the state-of-the-art Intel PMDK v1.5 STM, MOD improves map, set, stack, queue microbenchmark performance by 40%, and speeds up application benchmark performance by 38%.

Figures

Figures reproduced from arXiv: 1908.11850 by the authors.

Figure 1
Figure 1. For linked list defined in (a), implementation of prepend as (b) impure function with original list [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Fraction of execution time spent logging and flush [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Execution of concurrent flushes on Optane DCPMM. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (7 more)
Figure 5
Figure 5. Figure 5: Functional Shadowing in action on (a) MOD vector. [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: Failure-atomic Code Sections (FASEs) with MOD [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: Using the Composition interface for failure-atomically (a) appending an element to a vector, (a) swapping two elements [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: We discuss the memory reclamation needed to free [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]
Figure 8
Figure 8. Figure 8: (a) Implementation of Basic interface as a wrapper around the Composition interface. Commit implementation shown [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 9
Figure 9. Figure 9: Execution Time of PM workloads, normalized to [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]
Figure 11
Figure 11. Figure 11: L1D Cache miss ratios for PM workloads. 7. Related Work Prior works mainly consists of general optimizations for PM￾STM and specific optimizations for durable datastructures. 7.1. PM-STM Optimizations. Software approaches include Mnemosyne [47], NV-Heaps [7], SoftWrap…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

49 extracted references · 49 canonical work pages

  1. [1]

    Gene M. Amdahl. Validity of the single processor approach to achiev- ing large scale computing capabilities. In Proceedings of the April 18-20, 1967, Spring Joint Computer Conference (AFIPS), 1967

    work page 1967

  2. [2]

    nvm malloc: Memory allocation for nvram

    Tim Berning. nvm malloc: Memory allocation for nvram. https: //github.com/hyrise/nvm_malloc, 2017

    work page 2017

  3. [3]

    The parsec benchmark suite: Characterization and architectural im- plications

    Christian Bienia, Sanjeev Kumar, Jaswinder Pal Singh, and Kai Li. The parsec benchmark suite: Characterization and architectural im- plications. In Proceedings of the 17th International Conference on Parallel Architectures and Compilation Techniques (PACT), 2008

    work page 2008

  4. [4]

    Caulfield, Joel Coburn, Todor Mollov, Arup De, Ameen Akel, Jiahua He, Arun Jagatheesan, Rajesh K

    Adrian M. Caulfield, Joel Coburn, Todor Mollov, Arup De, Ameen Akel, Jiahua He, Arun Jagatheesan, Rajesh K. Gupta, Allan Snavely, and Steven Swanson. Understanding the impact of emerging non- volatile memories on high-performance, io-intensive computing. In Proceedings of the 2010 ACM/IEEE International Conference for High Performance Computing, Networking...

    work page 2010

  5. [5]

    Chakrabarti, Hans-J

    Dhruva R. Chakrabarti, Hans-J. Boehm, and Kumud Bhandari. Atlas: Leveraging locks for non-volatile memory consistency. In Proceed- ings of the 2014 ACM International Conference on Object Oriented Programming Systems Languages & Applications (OOPSLA), 2014

    work page 2014

  6. [6]

    Persistent b+-trees in non-volatile main memory

    Shimin Chen and Qin Jin. Persistent b+-trees in non-volatile main memory. Proceedings of the VLDB Endowment, 8, February 2015

    work page 2015

  7. [7]

    Caulfield, Ameen Akel, Laura M

    Joel Coburn, Adrian M. Caulfield, Ameen Akel, Laura M. Grupp, Ra- jesh K. Gupta, Ranjit Jhala, and Steven Swanson. NV-Heaps: Making Persistent Objects Fast and Safe with Next-generation, Non-volatile Memories. In Proceedings of the 16th International Conference on Architectural Support for Programming Languages and Operating Systems, 2011

    work page 2011

  8. [8]

    Nightingale, Christopher Frost, Engin Ipek, Benjamin Lee, Doug Burger, and Derrick Coetzee

    Jeremy Condit, Edmund B. Nightingale, Christopher Frost, Engin Ipek, Benjamin Lee, Doug Burger, and Derrick Coetzee. Better i/o through byte-addressable, persistent memory. In Proceedings of the ACM SIGOPS 22Nd Symposium on Operating Systems Principles (SOSP), 2009

    work page 2009

Show all 49 references
  1. [9]

    Two more approaches to persistent-memory writes

    Jonathan Corbet. Two more approaches to persistent-memory writes. https://lwn.net/Articles/731706/, 2017

    2017

  2. [10]

    Romulus: Effi- cient algorithms for persistent transactional memory

    Andreia Correia, Pascal Felber, and Pedro Ramalhete. Romulus: Effi- cient algorithms for persistent transactional memory. In Proceedings of the 30th on Symposium on Parallelism in Algorithms and Architectures (SPAA), 2018

    2018

  3. [11]

    Containers library

    cppreference. Containers library. https://en.cppreference.com/ w/cpp/container, 2018

    2018

  4. [12]

    The university of florida sparse matrix collection

    Tim Davis. The university of florida sparse matrix collection. http: //www.cise.ufl.edu/research/sparse/matrices

  5. [13]

    Driscoll, Neil Sarnak, Daniel D

    James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38, 1989

    1989

  6. [14]

    E. R. Giles, K. Doshi, and P. Varman. Softwrap: A lightweight frame- work for transactional support of storage class memory. In 2015 31st Symposium on Mass Storage Systems and Technologies (MSST), 2015

    2015

  7. [15]

    The recovery manager of the system r database manager

    Jim Gray, Paul McJones, Mike Blasgen, Bruce Lindsay, Raymond Lorie, Tom Price, Franco Putzolu, and Irving Traiger. The recovery manager of the system r database manager. ACM Computing Surveys (CUSR), 13, June 1981

    1981

  8. [16]

    Intel optane dc persistent memory operating modes explained

    Alper Ilkbahar. Intel optane dc persistent memory operating modes explained. https://itpeernetwork.intel.com/intel-optane- dc-persistent-memory-operating-modes/ , 2018

    2018

  9. [17]

    New release of pmdk

    Intel. New release of pmdk. https://pmem.io/2018/10/22/ release-1-5.html

    2018

  10. [18]

    Persistent memory development kit

    Intel. Persistent memory development kit. http://pmem.io/pmdk

  11. [19]

    Pmdk issues: introduce hybrid transactions

    Intel. Pmdk issues: introduce hybrid transactions. https://github. com/pmem/pmdk/pull/2716

  12. [20]

    Intel optane dc persistent memory readies for widespread deploy- ment

    Intel. Intel optane dc persistent memory readies for widespread deploy- ment. https://newsroom.intel.com/news/intel-optane-dc- persistent-memory-readies-widespread-deployment , 2018

    2018

  13. [21]

    Intel optane dc persistent memory

    Intel. Intel optane dc persistent memory. https: //www.intel.com/content/www/us/en/architecture- and-technology/optane-dc-persistent-memory.html , 2019

    2019

  14. [22]

    Failure-atomic persistent memory updates via justdo logging

    Joseph Izraelevitz, Terence Kelly, and Aasheesh Kolli. Failure-atomic persistent memory updates via justdo logging. In Proceedings of the Twenty-First International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), 2016

    2016

  15. [23]

    Dulloor, Jishen Zhao, and Steven Swanson

    Joseph Izraelevitz, Jian Yang, Lu Zhang, Juno Kim, Xiao Liu, Amir- saman Memaripour, Yun Joon Soh, Zixuan Wang, Yi Xu, Subra- manya R. Dulloor, Jishen Zhao, and Steven Swanson. Basic per- formance measurements of the intel optane DC persistent memory module. arXiv preprint, 2019

    2019

  16. [24]

    Ef- ficient persist barriers for multicores

    Arpit Joshi, Vijay Nagarajan, Marcelo Cintra, and Stratis Viglas. Ef- ficient persist barriers for multicores. In Proceedings of the 48th International Symposium on Microarchitecture (MICRO), 2015

    2015

  17. [25]

    Karp and Horace P

    Alan H. Karp and Horace P. Flatt. Measuring parallel processor perfor- mance. Communications of the ACM (CACM), 33, May 1990

    1990

  18. [26]

    Chen, Satish Narayanasamy, and Thomas F

    Aasheesh Kolli, Vaibhav Gogte, Ali Saidi, Stephan Diestelhorst, Pe- ter M. Chen, Satish Narayanasamy, and Thomas F. Wenisch. Language- level persistency. In Proceedings of the 44th Annual International Symposium on Computer Architecture (ISCA), 2017

    2017

  19. [27]

    Chen, and Thomas F

    Aasheesh Kolli, Steven Pelley, Ali Saidi, Peter M. Chen, and Thomas F. Wenisch. High-performance transactions for persistent memories. In Proceedings of the Twenty-First International Conference on Archi- tectural Support for Programming Languages and Operating Systems (ASPLOS), 2016

    2016

  20. [28]

    Chen, and Thomas F

    Aasheesh Kolli, Jeff Rosen, Stephan Diestelhorst, Ali Saidi, Steven Pelley, Sihang Liu, Peter M. Chen, and Thomas F. Wenisch. Dele- gated persist ordering. In The 49th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), 2016

    2016

  21. [29]

    Vetter, Gabriel Marin, Collin McCurdy, Cristian Cira, Zhuo Liu, and Weikuan Yu

    Dong Li, Jeffrey S. Vetter, Gabriel Marin, Collin McCurdy, Cristian Cira, Zhuo Liu, and Weikuan Yu. Identifying opportunities for byte- addressable non-volatile memory in extreme-scale scientific applica- tions. In Proceedings of the 2012 IEEE 26th International Parallel and Di...

    2012

  22. [30]

    Dudetm: Building durable transactions with decoupling for persistent memory

    Mengxing Liu, Mingxing Zhang, Kang Chen, Xuehai Qian, Yongwei Wu, Weimin Zheng, and Jinglei Ren. Dudetm: Building durable transactions with decoupling for persistent memory. In Proceedings of the Twenty-Second International Conference on Architectural Support for Programming L...

    2017

  23. [31]

    Q. Liu, J. Izraelevitz, S. K. Lee, M. L. Scott, S. H. Noh, and C. Jung. ido: Compiler-directed failure atomicity for nonvolatile memory. In 2018 51st Annual IEEE/ACM International Symposium on Microarchi- tecture (MICRO), 2018

    2018

  24. [32]

    Pmtest: A fast and flexible testing framework for persistent memory programs

    Sihang Liu, Yizhou Wei, Jishen Zhao, Aasheesh Kolli, and Samira Khan. Pmtest: A fast and flexible testing framework for persistent memory programs. In Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Syst...

    2019

  25. [33]

    Raymond A. Lorie. Physical integrity in a large segmented database. ACM Transactions on Database Systems (TODS), 2, March 1977

    1977

  26. [34]

    Nalli, S

    S. Nalli, S. Haria, M. D. Hill, M. M. Swift, H. V olos, and K. Keeton. An analysis of persistent memory use with whisper. In Proceedings of the Twenty-Second International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), 2017

    2017

  27. [35]

    Morrey III, Dhruva R

    Faisal Nawab, Joseph Izraelevitz, Terence Kelly, Charles B. Morrey III, Dhruva R. Chakrabarti, and Michael L. Scott. Dalí: A Periodically Persistent Hash Map. In 31st International Symposium on Distributed Computing (DISC), 2017

    2017

  28. [36]

    M. A. Ogleari, E. L. Miller, and J. Zhao. Steal but no force: Effi- cient hardware undo+redo logging for persistent memory systems. In 2018 IEEE International Symposium on High Performance Computer Architecture (HPCA), 2018

    2018

  29. [37]

    Purely Functional Data Structures

    Chris Okasaki. Purely Functional Data Structures . PhD thesis, Carnegie Mellon University, 1998

    1998

  30. [38]

    Chen, and Thomas F

    Steven Pelley, Peter M. Chen, and Thomas F. Wenisch. Memory persistency. In Proceeding of the 41st Annual International Symposium on Computer Architecuture (ISCA), 2014

    2014

  31. [39]

    Persistence for the masses: Rrb-vectors in a systems language

    Juan Pedro Bolívar Puente. Persistence for the masses: Rrb-vectors in a systems language. Proceedings of the ACM on Programming Languages, 1, September 2017

    2017

  32. [40]

    Proteus: A flexible and fast software supported hardware log- ging approach for nvm

    Seunghee Shin, Satish Kumar Tirukkovalluri, James Tuck, and Yan Solihin. Proteus: A flexible and fast software supported hardware log- ging approach for nvm. In Proceedings of the 50th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), 2017

    2017

  33. [41]

    Hiding the long latency of persist barriers using speculative execution

    Seunghee Shin, James Tuck, and Yan Solihin. Hiding the long latency of persist barriers using speculative execution. In Proceedings of the 44th Annual International Symposium on Computer Architecture (ISCA), 2017

    2017

  34. [42]

    Efficient Immutable Collections

    Michael Steindorfer. Efficient Immutable Collections . PhD thesis, University of Amsterdam, 2017. 12

    2017

  35. [43]

    Steindorfer and Jurgen J

    Michael J. Steindorfer and Jurgen J. Vinju. Optimizing hash-array mapped tries for fast and lean immutable jvm collections. In Pro- ceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), 2015

    2015

  36. [44]

    Rrb vec- tor: A practical general purpose immutable sequence

    Nicolas Stucki, Tiark Rompf, Vlad Ureche, and Phil Bagwell. Rrb vec- tor: A practical general purpose immutable sequence. In Proceedings of the 20th ACM SIGPLAN International Conference on Functional Programming (ICFP), 2015

    2015

  37. [45]

    Campbell

    Shivaram Venkataraman, Niraj Tolia, Parthasarathy Ranganathan, and Roy H. Campbell. Consistent and durable data structures for non- volatile byte-addressable memory. In Proceedings of the 9th USENIX Conference on File and Stroage Technologies (FASE), 2011

    2011

  38. [46]

    Intel memory latency checker v3.6

    Vish Viswanathan. Intel memory latency checker v3.6. https://software.intel.com/en-us/articles/intelr- memory-latency-checker , December 2018

    2018

  39. [47]

    V olos, A

    H. V olos, A. J. Tack, and M. M. Swift. Mnemosyne: Lightweight persistent memory. In Proceedings of the Sixteenth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), 2011

    2011

  40. [48]

    Dax: Page cache bypass for filesystems on memory storage

    Matthew Wilcox. Dax: Page cache bypass for filesystems on memory storage. https://lwn.net/Articles/618064/, 2014

    2014

  41. [49]

    Nv-tree: Reducing consistency cost for nvm-based single level systems

    Jun Yang, Qingsong Wei, Cheng Chen, Chundong Wang, Khai Leong Yong, and Bingsheng He. Nv-tree: Reducing consistency cost for nvm-based single level systems. In Proceedings of the 13th USENIX Conference on File and Storage Technologies (FAST), 2015. 13

    2015

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.