Oracle International Corporation

Steve Byan

Virendra J Marathe

Margo I Seltzer

Achin Mishra

Amee Trivedi

Yihe Huang

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.

Persistent memory transactions with undo logging

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.

Data structure store in persistent memory

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.

Committing copy-on-write transaction with a persist barrier for a persistent object including payload references

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.

Growing community of inventors

Littleton, MA, United States of America

Steve Byan