Abstract: Undo logging for persistent memory transactions may permit concurrent transactions to write to the same persistent object. After an undo log record has been written, a single persist barrier may be issued. The tail pointer of the undo log may be updated after the persist barrier, and without another persist barrier, so the tail update may be persisted when the next log record is written and persisted. Undo logging for persistent memory transactions may rely on inferring the tail of an undo log after a failure rather than relying on a guaranteed correct tail pointer based on persisting the tail after every append. Additionally, transaction version numbers and checksum information may be stored to the undo log enabling failure recovery.

Abstract: Undo logging for persistent memory transactions may permit concurrent transactions to write to the same persistent object. After an undo log record has been written, a single persist barrier may be issued. The tail pointer of the undo log may be updated after the persist barrier, and without another persist barrier, so the tail update may be persisted when the next log record is written and persisted. Undo logging for persistent memory transactions may rely on inferring the tail of an undo log after a failure rather than relying on a guaranteed correct tail pointer based on persisting the tail after every append. Additionally, transaction version numbers and checksum information may be stored to the undo log enabling failure recovery.

Abstract: Undo logging for persistent memory transactions may permit concurrent transactions to write to the same persistent object. After an undo log record has been written, a single persist barrier may be issued. The tail pointer of the undo log may be updated after the persist barrier, and without another persist barrier, so the tail update may be persisted when the next log record is written and persisted. Undo logging for persistent memory transactions may rely on inferring the tail of an undo log after a failure rather than relying on a guaranteed correct tail pointer based on persisting the tail after every append. Additionally, transaction version numbers and checksum information may be stored to the undo log enabling failure recovery.

Abstract: A persistent data structure store may include an architecture that utilizes dual representations of data hosted in persistent storage coupled with a faster non-persistent cache residing in volatile memory. The persistent data structure store may maintain, in a non-volatile persistent memory, a byte-addressable persistent copy of a data structure storing multiple data values. The persistent data structure store may also maintain a copy of at least some of the data values in a cache copy of the data structure in a volatile memory. When updating values in the data structure, the targeted data value may be updated in the cache copy of the data structure and a log entry specifying the data update may be added to a cross-referencing data operations log from which the data operation will be subsequently applied to the persistent copy of the data structure.

Abstract: Systems implementing copy-on-write (COW) as described herein may reduce the number of persist barriers executed within a transaction. For instance, a system may eliminate some, most or all persist barriers related to memory allocation/deallocation in COW transactions. A COW implementation may introduce an extra level of indirection between a persistent type instance and the real data type it encloses. A persistent type may include pointers to old and new versions of the enclosed type's instances. Before modifying an object, a transaction may modify a copy-on-write persistent object and create a new copy of the payload. The modified object may be added to a list of objects written to by the transaction. The transaction may be committed by issuing persist barriers in the commit operation.

Abstract: Applications may allocate and deallocate persistent objects within transactions used to access persistent data. An allocator's persistent metadata may be lazily persisted when the enclosing transaction commits. An allocator's metadata may be divided into persistent and nonpersistent portions while the heap may be divided into shared and thread-private superblocks. The persisting of the effects of allocation/deallocation calls may be lazily performed and bundled with the enclosing transaction's commit operation related persist barriers. A transaction may maintain an allocation log of the allocation/deallocation calls made by the transaction. An allocation log may be hosted in persistent memory and updated during allocation/deallocation calls. No persist barriers may be used during allocation/deallocation calls. Before a transaction commits, its updates and allocation log may be persisted. Once the transaction has been committed, the allocation log may be applied to the heap's corresponding metadata.

Abstract: A persistent data structure store may include an architecture that utilizes dual representations of data hosted in persistent storage coupled with a faster non-persistent cache residing in volatile memory. The persistent data structure store may maintain, in a non-volatile persistent memory, a byte-addressable persistent copy of a data structure storing multiple data values. The persistent data structure store may also maintain a copy of at least some of the data values in a cache copy of the data structure in a volatile memory. When updating values in the data structure, the targeted data value may be updated in the cache copy of the data structure and a log entry specifying the data update may be added to a cross-referencing data operations log from which the data operation will be subsequently applied to the persistent copy of the data structure.

Abstract: Applications may allocate and deallocate persistent objects within transactions used to access persistent data. An allocator's persistent metadata may be lazily persisted when the enclosing transaction commits. An allocator's metadata may be divided into persistent and nonpersistent portions while the heap may be divided into shared and thread-private superblocks. The persisting of the effects of allocation/deallocation calls may be lazily performed and bundled with the enclosing transaction's commit operation related persist barriers. A transaction may maintain an allocation log of the allocation/deallocation calls made by the transaction. An allocation log may be hosted in persistent memory and updated during allocation/deallocation calls. No persist barriers may be used during allocation/deallocation calls. Before a transaction commits, its updates and allocation log may be persisted. Once the transaction has been committed, the allocation log may be applied to the heap's corresponding metadata.

Abstract: Systems implementing copy-on-write (COW) as described herein may reduce the number of persist barriers executed within a transaction. For instance, a system may eliminate some, most or all persist barriers related to memory allocation/deallocation in COW transactions. A COW implementation may introduce an extra level of indirection between a persistent type instance and the real data type it encloses. A persistent type may include pointers to old and new versions of the enclosed type's instances. Before modifying an object, a transaction may modify a copy-on-write persistent object and create a new copy of the payload. The modified object may be added to a list of objects written to by the transaction. The transaction may be committed by issuing persist barriers in the commit operation.

Abstract: Undo logging for persistent memory transactions may permit concurrent transactions to write to the same persistent object. After an undo log record has been written, a single persist barrier may be issued. The tail pointer of the undo log may be updated after the persist barrier, and without another persist barrier, so the tail update may be persisted when the next log record is written and persisted. Undo logging for persistent memory transactions may rely on inferring the tail of an undo log after a failure rather than relying on a guaranteed correct tail pointer based on persisting the tail after every append. Additionally, transaction version numbers and checksum information may be stored to the undo log enabling failure recovery.

Abstract: A mutable multilevel data structure representing a graph structure may include multiple read-only levels and a single writable level. Each read-only level may include a vertex table (with references to edge tables on the same level or a different level containing elements of adjacency lists for some vertices) and an edge table (with elements of adjacency lists that changed since the previous read-only level). A hybrid variant may switch between a performance-optimized variant (whose edge tables include complete adjacency lists for vertices whose edge sets were modified) and a space-optimized variant (whose edge tables include only newly added adjacency list elements). The vertex tables and/or the writable level may be implemented using copy-on-write arrays, each including an indirection table and multiple fixed-sized data pages. Computations may be run on the read-only levels or on the writable level and read-only levels.

Abstract: A mutable multilevel data structure representing a graph structure may include multiple read-only levels and a single writable level. Each read-only level may include a vertex table (which includes references to edge tables on the same level or a different level containing elements of adjacency lists for some vertices) and an edge table (which includes elements of adjacency lists that changed since the previous read-only level). A hybrid variant may switch between a performance-optimized variant (whose edge tables include complete adjacency lists for vertices whose edge sets were modified) and a space-optimized variant (whose edge tables include only newly added adjacency list elements). The vertex tables and/or the writable level may be implemented using copy-on-write arrays, each including an indirection table and multiple fixed-sized data pages. Computations may be run on the read-only levels or on the writable level and read-only levels.