WO2016111702A1 - Récupération de données superflues de mémoire persistante - Google Patents

Récupération de données superflues de mémoire persistante Download PDF

Info

Publication number
WO2016111702A1
WO2016111702A1 PCT/US2015/010862 US2015010862W WO2016111702A1 WO 2016111702 A1 WO2016111702 A1 WO 2016111702A1 US 2015010862 W US2015010862 W US 2015010862W WO 2016111702 A1 WO2016111702 A1 WO 2016111702A1
Authority
WO
WIPO (PCT)
Prior art keywords
program
persistent
memory
free
list
Prior art date
Application number
PCT/US2015/010862
Other languages
English (en)
Inventor
Dhruva Chakrabarti
Kumud BHANDARI
Original Assignee
Hewlett Packard Enterprise Development Lp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development Lp filed Critical Hewlett Packard Enterprise Development Lp
Priority to PCT/US2015/010862 priority Critical patent/WO2016111702A1/fr
Priority to US15/538,377 priority patent/US10949342B2/en
Publication of WO2016111702A1 publication Critical patent/WO2016111702A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory

Definitions

  • memory refers to the physical devices used to store programs (e.g., sequences of machine readable instructions) or data (e.g., program state information) on a temporary or permanent basis for use in a computer or other digital electronic device.
  • programs e.g., sequences of machine readable instructions
  • data e.g., program state information
  • garbage collection is a form of memory management. Garbage collection includes reclaiming garbage or memory occupied by objects that are no longer in use by a program.
  • Figure 1 illustrates an architecture of a persistent memory garbage collection apparatus, according to an example of the present disclosure
  • Figure 2 illustrates a persistent region of a persistent memory, according to an example of the present disclosure
  • Figure 3 illustrates allocation, initialization, and publication of persistent data, according to an example of the present disclosure
  • Figure 4 illustrates a failure atomic section in the absence of an offline garbage collection module, according to an example of the present disclosure
  • Figure 5 illustrates various stages in the management of persistent memory, according to an example of the present disclosure
  • Figure 6 illustrates a method for persistent memory garbage collection, according to an example of the present disclosure
  • Figure 7 illustrates further details of the method for persistent memory garbage collection, according to an example of the present disclosure
  • Figure 8 illustrates further details of the method for persistent memory garbage collection, according to an example of the present disclosure.
  • Figure 9 illustrates a computer system, according to an example of the present disclosure.
  • the terms “a” and “an” are intended to denote at least one of a particular element.
  • the term “includes” means includes but not limited to, the term “including” means including but not limited to.
  • the term “based on” means based at least in part on.
  • persistent memory includes any type of memory for efficiently storing data structures such that the data structures can continue to be accessed using memory instructions or memory application programming interfaces (APIs) even after the end of the process that created or last modified the data structures.
  • Figure 2 illustrates a persistent region of a persistent memory, according to an example of the present disclosure.
  • a persistent region may represent a contiguous space of memory in non-volatile random-access memory (NVRAM) identified by a unique identification (ID) (e.g., rgn_id).
  • ID unique identification
  • a dynamically allocated persistent memory i.e., a persistent heap
  • a persistent heap may exist within the realm of a persistent region.
  • Figure 2 illustrates nvm_heap 0 (i.e., non-volatile memory (NVM) heap 0), and nvm_heap 1 .
  • NVM non-volatile memory
  • a persistent region may include a set of persistent roots which stores the starting addresses of each separately managed persistent heap existing within a region.
  • nvm_heap 0 and nvm_heap 1 are two examples of such persistent heaps being managed under two separate memory allocation schemes.
  • a persistent heap may not be contiguous as a result of expanding a persistent heap, but all different dis-contiguous sections of the persistent heap may lie within the same region.
  • nvm_heap 0, which has two dis-contiguous sections is an example of such a persistent heap.
  • persistent memory technologies may be available to user-level programs as large, byte-addressable NVRAM, complementing the existing dynamic random-access memory (DRAM).
  • a computer program i.e., machine readable instructions
  • a computer program that manipulates persistent data residing in NVRAM and expects the data to be reused beyond the program's lifetime should do so in a manner that preserves the consistent state of the data beyond tolerated failures and system restarts (i.e., for a system that hosts or otherwise utilizes the computer program).
  • such a computer program should not permanently leak memory as a result of a failure or a programming error.
  • a permanent memory leak in NVRAM may be more harmful than for transient memory because such leaks may accumulate over time and consume a relatively large portion of the memory. Even a program that is considered leak-free may cause memory leaks when manipulating persistent data due to events such as failures that are beyond the control of a programmer.
  • Figure 3 illustrates allocation, initialization, and publication of persistent data, according to an example of the present disclosure.
  • Statement-1 may represent allocation of memory
  • statement-2 may represent initialization of the memory allocated in statement-1
  • statement-3 may represent publication, where a pointer to the newly allocated memory may be assigned to a globally visible location (e.g., the persistent_root).
  • memory may be allocated and published externally but that memory has not yet been initialized.
  • the above reordering may be possible in a system with out-of-order execution processors and data caches positioned in between NVRAM and the processor. Assuming such caches are volatile, a failure after the execution of statement-1 leaves a dangling pointer in the persistent heap, while a failure after the execution of statement-1 and statement-3, and before the execution of statement-2, leaves a pointer to an uninitialized address in the persistent heap.
  • a failure or a programming error should not make some part of NVRAM permanently inaccessible in the form of permanent leaks.
  • Figure 3 according to another scenario where the effects of the program statements become visible in the order of the program statement-1 , statement-2, and statement-3, even in such a scenario, without any contingency to reclaim memory after tolerated failures, such a failure anywhere after the execution of statement-1 and before the execution of statement-3, may cause a permanent memory leak.
  • a leak in persistent memory may be permanent as it may not be resolved by restarting a system, and may further build up to consume a relatively large portion of the persistent memory.
  • Garbage collection for persistent memory includes a close operational connection between a memory allocator and a garbage collector.
  • a memory allocator may allocate portions of memory to programs at their request, and free portions of the memory for reuse when no longer needed.
  • garbage collection is based on locating all pointers (or references) in program data structures. For example, a memory analyzer that operates in conjunction with the memory allocator examines a bit pattern to determine whether the bit pattern is a pointer. If the memory analyzer determines that the bit pattern appears to be a pointer, the memory analyzer interprets the bit pattern as a pointer.
  • a mark-sweep garbage collection operation follows these pointers to mark all reachable locations in the memory. Any object that is not marked is garbage and is reclaimed (e.g., via a sweep operation) by the garbage collector. This technique is conservative since objects that are actually garbage appear reachable based on pointers and hence are not claimed. However, some objects that are garbage may appear reachable and may not be claimed. This may occur because of inherent inaccuracies in pointer identification.
  • a persistent memory garbage collection apparatus and a method for persistent memory garbage collection are disclosed herein.
  • the apparatus and method may generally provide for the management of internal persistent garbage collection data structures in a failure-resilient manner and with minimum execution overhead. This ensures that on re-execution (e.g., of an application including machine readable instructions), the memory allocation module for the persistent memory continues to function correctly. For example, in the event of failure, the garbage collection data structures may not be re-usable in further instantiations of an application.
  • the apparatus and method disclosed herein may also ensure that the memory allocation module performance is not degraded, and recovery (if any, after a failure) is achieved in an expedited manner. Further, the apparatus and method disclosed herein may reduce memory leaks for persistent memory while maintaining high performance of the memory allocation module.
  • the apparatus and method disclosed herein generally provide for dynamic management of persistent memory that combines the performance benefits of explicit persistent memory management online (i.e., when an application is being executed) with the safety benefits of an offline cleanup/recovery time conservative garbage collection.
  • a specified recovery time against memory leaks may improve both the performance as well as the programmability of the persistent memory APIs by removing the restriction on the placement of memory management operations in relation to failure atomic sections.
  • the apparatus and method disclosed herein may provide a failure resilient memory allocation module that allocates persistent memory and provides for explicit persistent memory management during the execution of a program while reclaiming leaked persistent memory during cleanup after a normal exit from a program, or during a recovery phase after an abnormal exit a program.
  • the phase of persistent memory management (e.g., via a memory management scheme (MMS) as described herein) where a mutator (i.e., to control changes to a variable) is absent may be designated as offline, and the phase of persistent memory management where the mutator is executing as online.
  • the memory allocation module and the garbage collection module may execute on two distinct phases including online and offline.
  • FIG. 4 illustrates a failure atomic section in the absence of an offline garbage collection module, according to an example of the present disclosure.
  • an array of two elements may be allocated in persistent memory in statement-4, initialized and manipulated in statements 5-9, and reachability from a persistent root may be established in statements 10-12.
  • statements 4-14 may need to be enclosed in a failure atomic section because a failure anywhere after the execution of statement-4 and before the execution of either statement-12 or statement-14 may leak memory.
  • Stores to persistent locations within failure atomic sections may incur performance overhead based on a mechanism used to implement failure atomicity (e.g., transactional logs).
  • the presence of an offline garbage collection module as disclosed herein may allow placement of the allocation (e.g., nvm malloc on statement-4) and deallocation (e.g., free on statement-14) clauses to be placed outside the failure atomic section in the example of Figure 4.
  • the offline garbage collection module of the apparatus and method disclosed herein may turn failures from resource leaking events to resource freeing opportunities. These aspects may provide for more frequent staging of such failures as a part of ongoing software (i.e., machine readable instructions) development or maintenance. These aspects may also facilitate testing of recovery logic to mitigate the effect of actual failures.
  • the DRAM and NVRAM may be both available simultaneously as byte-addressable memory to user programs mapped into a same virtual address space and accessible through central processing unit (CPU) load and store instructions.
  • CPU central processing unit
  • hierarchies of volatile caches may be shared by both the DRAM and NVRAM. These caches may treat volatile and non-volatile data equally.
  • an underlying system may provide a mechanism such as clflush
  • the apparatus and method disclosed herein may provide for the toleration of any software and system failures such as program aborts, kernel panics, and power failures without any additional changes to an existing architecture's instruction set architecture or the microarchitecture.
  • the apparatus and method disclosed herein may include a MMS that is implemented by the memory allocation module to detect failure during the last allocation or collection cycle related to a persistent memory, and the nature of a failure.
  • the MMS may invoke recovery logic to re-establish internal consistency as a part of an offline restart logic.
  • the apparatus and method disclosed herein may utilize a conservative mark-and-sweep operation for the garbage collection module to distinguish valid memory addresses from arbitrary bit patterns in the persistent heap and to determine the size of the memory space pointed by a valid persistent heap address so that all bit patterns may be examined.
  • a conservative mark-and-sweep operation for the garbage collection module any bit pattern that is not within a range of maximum and minimum persistent heap addresses may be discarded. If a bit pattern is within the range of maximum and minimum persistent heap address, if such a bit pattern points to the unallocated portion of the persistent heap, such a bit pattern may also be discarded.
  • bit pattern is within the range of maximum and minimum persistent heap address but does not point to the unallocated portion of the persistent heap, if such a bit pattern points to the middle of the allocated block, such a bit pattern may also be discarded. Further, if a bit pattern is within the range of maximum and minimum persistent heap address but does not point to the unallocated portion of the persistent heap and does not point to the middle of the allocated block, such a bit pattern may be considered a valid address and the allocated objects that is referenced to may be retained.
  • Figure 1 illustrates an architecture of a persistent memory garbage collection apparatus (hereinafter also referred to as "apparatus 100"), according to an example of the present disclosure.
  • the apparatus 100 is depicted as including a memory allocation module 102 to determine whether termination of a program 104 is based on a specified termination (e.g., an exit during or after program execution, etc.) of the program 104 during execution of the program 104, or an unspecified termination (e.g., process failures, kernel panics, power outages, etc.) of the program 104 during the execution of the program 104.
  • a specified termination e.g., an exit during or after program execution, etc.
  • an unspecified termination e.g., process failures, kernel panics, power outages, etc.
  • the memory allocation module 102 may utilize persistent metadata 106 stored in a persistent memory 108 to restart the program 104. Further, in response to a determination that the termination of the program 104 is based on the unspecified termination of the program 104 during the execution of the program 104, the memory allocation module 102 may operate in conjunction with a garbage collection module 110 to utilize the persistent metadata 106 stored in the persistent memory 108 to collect garbage from the persistent memory 108 and to restart the program 104.
  • the MMS of the apparatus 100 may acquire persistent memory 108, for example, from an underlying system, and use the persistent memory 108 to fulfill requests from various applications.
  • the persistent memory 108 may persist persistent metadata 106 related to past actions of the memory allocation module 102 and the garbage collection module 110 to create a consistent view of the memory space that is under the management of the memory allocation module 102 upon restart of a program that uses the persistent memory 108.
  • the memory allocation module 102 may avoid memory leaks as a result of failure, and avoid user data corruption in a persistent heap due to memory management errors such as multiple allocations or deallocations of the same space.
  • the persistent metadata 106 that is needed across restarts of a program that uses the persistent memory 108 may be sorted into a persistent data structure, with the consistency of the persistent metadata 106 being ensured before use thereof. Any temporary metadata which does not need to be persisted across restarts may be maintained in transient memory.
  • the persistent metadata 106 may include metadata related to a free-list 112, headers 114, header indices 116, persistent roots 118, and consistency log 120.
  • the free-list 112 may generally identify the persistent memory 108 that has not been allocated.
  • the headers 114 may generally identify allocated memory objects within an associated memory page of the persistent memory 108.
  • the headers 114 of allocated chunks of the persistent memory 108 may specify information such as the size of allocation.
  • the header indices 116 may generally map given memory page addresses to memory locations in the persistent memory 108 where the header information for corresponding memory pages are stored.
  • the persistent roots 118 may generally identify the starting addresses of each separately managed persistent heap existing within a persistent region.
  • the consistency log 120 may generally identify modifications related to allocation of the persistent memory 108.
  • the apparatus 100 may use a persistent heap which includes a collection of objects with possible pointers among them. For an object to be persisted, the object is allocated out of a persistent heap. As described with reference to Figure 2, a persistent heap may include a persistent root (or a plurality of roots) that is in turn allocated out of the same persistent heap, and is hence persistent. With respect to garbage collection in this environment, at stable execution points (e.g., after program termination), any object within a persistent heap not reachable from any of the persistent roots of the object may be
  • any object within a persistent heap obeys the natural invariant that if the object is not reachable from any persistent heap roots or any program roots (e.g., from the stack and registers), the object may be considered garbage and reclaimed.
  • the MMS of the apparatus 100 may allocate the persistent metadata 106 into a persistent scratch space 122 of the persistent memory 108.
  • the persistent scratch space 122 may be acquired separately from the persistent heap space, and may not be garbage collected.
  • a persistent bump pointer may be used to track the free space of the persistent scratch space 122. With the exception of page headers, no objects allocated in the persistent scratch space 122 may be deallocated. Deallocated header spaces may be reused to fulfill new header requests by maintaining such spaces in the free-list 112 known as header free-list. Both the space acquisition and the update to the free space bump pointer may occur failure atomically to avoid any failure induced memory leaks.
  • the free space may be expanded as needed by acquiring more memory from the persistent memory 108. Any newly acquired space may be contiguous or separated from the previous space. For the persistent scratch space, some memory may not be used at the end of a persistent scratch space due to a mismatch between the size of the object being allocated and the remaining memory.
  • Isolation of the persistent metadata 106 from the persistent heap space may provide additional security against inadvertent corruption of the persistent metadata 106, and facilitate locality of reference for both the persistent metadata 106 and user data.
  • An MMS initialization routine may be used to return the start address of the first persistent scratch space.
  • garbage collection may be performed by the garbage collection module 110 in an online mode, an offline mode, or both.
  • An online mode of the garbage collection module 110 may refer to garbage collection as a program (i.e., machine readable instructions) is executing.
  • An offline mode of the garbage collection module 110 may refer to garbage collection during the recovery phase if program execution is interrupted by a failure.
  • the online or offline modes of the garbage collection module 110 may reclaim garbage created, for example, by program error and by failures.
  • the offline mode of the garbage collection module 110 may operate independently of program execution. For the offline mode operation of the garbage collection module 110, ambiguous program roots such as stacks and registers may be omitted, and operation of the garbage collection module 110 may instead begin from well-identified persistent heap roots.
  • the garbage collection internal data structures that are accessed by the garbage collection module 110 may include transient and persistent data structures. With respect to separation of transient and persistent garbage collection internal data structures, a minimum core set of persistent data structures without which the memory allocation module 102 cannot function after re-execution may be maintained as the persistent metadata 106.
  • the minimum core set of persistent data structures may be manipulated with failure-atomic CPU instructions. Whenever the minimum core set of persistent data structures are not manipulated with failure-atomic CPU instructions, the consistency of the minimum core set of persistent data structures may be maintained either by garbage collection internal logging (i.e., by the consistency log 120) or using shadowing techniques.
  • the core data structures may include, for example, the free-list 112, the headers 114, the header indices 116, the persistent roots 118, and the consistency log 120.
  • the free-list 112 of the memory allocation module 102 may represent the persistent memory 108 that has not been allocated.
  • the free-list 112 may be maintained in the persistent metadata 106 of the persistent memory 108 in a failure-resilient manner. For example, all modifications related to the free-list 112 may be logged in the consistency log 120, which may be replayed in the event of a failure.
  • the consistency of the free-list 112 may be maintained regardless of failures. Thus, updates to the free-list 112 may be logged to the consistency log 120 during program execution. Before updating any element of the free-list 112, the location being updated and its previous value may be entered into the consistency log 120. If a failure occurs during the update to the free-list 112, the consistency log 120 entries may be replayed during recovery to revert the free-list 112 back to a consistent state.
  • an alternative may be to forego maintaining consistency of the free-list 112 in the presence of failures.
  • the free-list 112 may be specified as being consistent if a program terminates successfully. A bit maintained in the
  • the implementation may track the status of program termination.
  • the free-list 112 may be reused. However, in the event of a failure, the free-list 112 may be discarded and the recovery phase may rebuild the free-list 112. For example, the free-list 112 may be rebuilt from the headers 114 maintained in the persistent metadata 106 for every page. Thus persistent data structures may be maintained for communication across successive executions without the overhead of maintaining consistency.
  • the free-list 112 may be visible in the persistent memory 108.
  • the free-list may be flushed out of volatile CPU buffers and caches.
  • the free-list 112 may include an object free-list and a page free-list.
  • the object free-list may represent a singly linked list of free persistent memory objects whose sizes are less than a page.
  • a persistent memory object is a contiguous chunk of memory identified by a unique starting address.
  • the granules for which the object free-list exists up to the maximum number of granules supported may depend on the persistent memory 108 requests that have been received.
  • an object free-list for thirty-two bytes may not exist if a request for such an object free-list has not been received.
  • Each of these object free-lists may be reachable through a pointer element in an array.
  • an I th pointer element may point to the object free-list of / granules.
  • This array may also be allocated at a known location within the first persistent scratch space 122.
  • a link to the next object in the object free-list may be installed within the object (last sixty- four bits of the unallocated object in object free-list).
  • the object free-list may be maintained in the persistent scratch space 122 so that any unallocated object in the object free-list is not lost temporarily, where next garbage collection will eventually find such an unallocated object, across normal restarts.
  • the failure consistency of the object free-list may be maintained in the absence of failure. In case of a failure, the garbage collection module 110 may be used rebuild the object free-list.
  • contiguous free space that is page-sized or larger may be stored in the page free-list. Similar to the object free-list, the free unallocated space of the persistent memory 108 may be segregated by the number of pages up to a threshold (e.g., sixty pages).
  • Contiguous spaces with a number of pages higher than the threshold may be stored in the last page free-list (e.g., 60+ pages free-list).
  • Each of these page free- lists may be reachable through a pointer element in an array allocated at a known location within the initial search space of the persistent memory 108. In this array, an I th element is a pointer to the page free-list with / ' number of pages.
  • the consistency of the page free-list may be implemented in the absence of failure.
  • the MMS may use state and
  • a pre-defined amount of space may be allocated for creating the consistency log 120.
  • space for the consistency log 120 may be allocated at a known offset in the initial persistent heap.
  • a mark stack may be maintained in transient memory and is an example of a transient garbage collection internal data structure.
  • the persistent mark bits may be used to skip over the task already performed in the previous execution. Maintaining the mark stack in transient memory avoids the overhead of failure-resilience, with minimal loss with respect to performance of the memory allocation module 102.
  • Mark bits that indicate whether a particular chunk of the persistent memory 108 is reachable, may be maintained in the persistent memory 108.
  • the mark bits may be updated using failure-atomic CPU instructions.
  • the MMS of the apparatus 100 may maintain information with respect to all allocated memory objects within a page in a header for that page.
  • all of the objects contained in a page may be of the same size.
  • the aspect of the same page size may provide for the maintenance of a single header for all objects in a page.
  • the aspect of the same page size may also reduce the number of items whose failure consistency has to be maintained, thus reducing the overall failure consistency overhead of the MMS.
  • the object free-list may be refilled by splitting a page from a contiguous block in the page free-list, allocating the memory space into multiple objects of the same granule, and adding the objects to the appropriate free-list.
  • a single header may be installed for a page, and a size field for the header may be updated to indicate the size of memory objects in that page.
  • Each first page of a contiguous free space in the page free-list may also include a header.
  • the size field of the header may include the total size in bytes of the contiguous space.
  • a header may also include a mark bits field to mark each memory object in a page as reachable or unreachable.
  • Figure 5 illustrates various stages in the management of the persistent memory 108, according to an example of the present disclosure.
  • the garbage collection module 110 may be initialized.
  • the persistent metadata 106 may be initialized.
  • the memory allocation module 102 may acquire new persistent heap memory from the persistent memory 108.
  • the garbage collection module 110 may initiate the online restart process.
  • online restart may include restarting by using the persistent metadata 106.
  • a memory request to the persistent memory 108 may be fulfilled.
  • the memory allocation module 102 may acquire new persistent heap memory from the persistent memory 108.
  • the memory request at 512 may be closed, and the persistent heap may be closed.
  • the garbage collection module 110 may initiate the offline recovery process.
  • garbage collection may be executed to initiate recovery and restart.
  • garbage may be collected from the persistent memory 108.
  • the persistent heap may be closed.
  • the MMS may acquire a space for the initial persistent scratch space 122, allocate all pertinent data structures, and acquire the initial persistent heap space.
  • the MMS may store a restart number in the initial persistent scratch space 122, set a consistency flag to FAILED, and return the starting address of the initial persistent scratch space 122.
  • the restart number may be used by restart code (i.e., machine readable instructions) to verify that a given address is indeed a start of the properly initialized initial persistent scratch space 122.
  • the MMS may check if the start address provided is a start of a properly initialized MMS metadata, and initialize itself using the stored data. If the MMS detects a FAILED previous exit, the MMS may first replay the consistency log 120. Next, if needed, the MMS may recreate some of the data structures of the persistent memory 108. At the end of the recovery, the MMS may accept any memory management requests, including request for offline garbage collection. Any failure before the end of a successful restart phase may leave the MMS in the same state as it was at the beginning of the restart.
  • offline garbage collection may start at the request of the user-application and/or API.
  • the offline garbage collection may include allocation of a mark stack in the transient scratch space to hold memory objects in the persistent heap that are to be analyzed by the mark process.
  • the MMS may iterate through a set of persistent root pointers and push the persistent root pointers into the mark stack.
  • the MMS may pop a memory object from the mark stack at a time, and examine, for example, each eight-byte aligned bits within the object for a potential memory reference.
  • the MMS may set the mark bit (as reachable) for the memory object referenced by the memory reference.
  • the MMS may then push the referenced memory object into the mark stack.
  • the MMS may empty the mark stack by exploring each object in the mark stack.
  • the MMS may then resize the mark stack and rescan the entire persistent heap for pointers from the explored objects to the unexplored objects.
  • a failure during the mark phase does not leave the MMS in an inconsistent state, in which case, the collection of memory objects may be completed on restart.
  • the MMS may release all memory objects in the free-list 112 and reclaim list, and rebuild the reclaim list from scratch.
  • the reclaim list may include a list of memory pages where all reachable memory objects (memory objects currently in use) have been marked, but the free memory objects within the page have not yet been reclaimed and added to the object free- list.
  • the MMS may iterate through each bucket node in a tree. The MMS may fetch each header in the bucket node with a valid address, and examine the flags. For each header whose flag is set to ASSIGNED, the MMS may examine the mark bits.
  • the entire free page may be flagged as FREE and returned to the page free-list.
  • the MMS may attempt to coalesce the free page with immediately preceding or succeeding adjacent free space before returning the free page to the page free-list. If some mark bits are set in its header, the free page may be returned to the appropriate reclaim list based on the size of the object stored by the free page. A failure during the coalescing of free pages may leave the MMS in an inconsistent state or leak memory. Any memory page for which a header has not been installed may be considered a leak as it is unreachable.
  • a memory page or a set of contiguous memory pages may not have a corresponding header momentarily, or more than one header may account for the same memory page.
  • a header that is available as a result of coalescing may be added to the header free-list atomically to avoid leaking the persistent scratch space 122.
  • the header free-list may include persistent memory objects which at some point were used to store header information of some memory page, but currently is free and may be used to store header information of another page in the future.
  • a space acquired from the persistent memory 108 may not be available to the memory allocation module 102 until a header has been installed for the space and added to the page free-list.
  • a new header may be allocated and installed in a header index tree and the memory space may be added to page free-list.
  • the MMS may coalesce the new space with the preceding or succeeding contiguous preceding free space in the page free-list.
  • a contiguous space in the page free-list may be divided into two halves such that the first half is either a single page used for refilling the object free-list, or is a collection of pages equal to the requested size of an allocation (rounded up to a multiple of a memory page size).
  • the second unallocated half a new header may be allocated, the size of the unallocated half may be updated to reflect the size of the unallocated space, the flag in the header of the unallocated half may be updated to FREE, and a new header for the unallocated half may be installed in a header index table.
  • the second unallocated half may be added to the page free-list appropriate to the new size of the second unallocated half.
  • a size field may be updated to the rounded requested size, and the flag may be set to ASSIGNED from FREE.
  • the header installation for the first allocated half may further involve allocating a new bucket in the header index table. If the allocated first half is a large allocation containing multiple pages, a forwarding address may be installed. A failure in the middle of a crash may potentially cause memory leak in terms of a lost second half if the failure occurs before the installation of a header. Such a failure may leave dangling pointers in the free-list 112 or in the header index table. Due to a failure, the sizes for the two halves may not be consistent, which may result in a memory leak or memory corruption.
  • a deallocation of an object smaller than a page may be performed by looking up the header for the given address, by obtaining the object size
  • a relatively large object may include a forwarding address that needs to be set back to zero in the header index table's bucket node entries. An incomplete resetting of the forwarding address may be completed during the recovery phase after a failure during the process which may be detected using a flag.
  • the MMS may ensure that all persistent memory updates which have not yet been specified as being visible, but are needed for consistency, are made visible. Thus all updated addresses waiting to be flushed from volatile cache may be flushed ensuring that all updates to persistent data structures which are needed for consistency are visible in the persistent memory 108. The MMS may then set the MMS consistency state from FAILED to NORMAL.
  • the modules and other elements of the apparatus 100 may be machine readable instructions stored on a non-transitory computer readable medium.
  • the apparatus 100 may include or be a non-transitory computer readable medium.
  • the modules and other elements of the apparatus 100 may be hardware or a combination of machine readable instructions and hardware.
  • Figures 6-8 respectively illustrate flowcharts of methods 600, 700, and 800 for persistent memory garbage collection, corresponding to the example of the persistent memory garbage collection apparatus 100 whose construction is described in detail above.
  • the methods 600, 700, and 800 may be implemented on the persistent memory garbage collection apparatus 100 with reference to Figures 1 , 2, and 5 by way of example and not limitation.
  • the methods 600, 700, and 800 may be practiced in other apparatus.
  • the method may include determining whether termination of a program is based on a specified termination of the program during execution of the program or an unspecified termination of the program during the execution of the program.
  • the memory allocation module 102 may determine whether termination of the program 104 is based on a specified termination (e.g., an exit during or after program execution, etc.) of the program 104 during execution of the program 104, or an unspecified termination (e.g., process failures, kernel panics, power outages, etc.) of the program 104 during the execution of the program 104.
  • a specified termination e.g., an exit during or after program execution, etc.
  • an unspecified termination e.g., process failures, kernel panics, power outages, etc.
  • the method may include utilizing persistent metadata stored in a persistent memory to restart the program.
  • the memory allocation module 102 may utilize persistent metadata 106 stored in the persistent memory 108 to restart the program 104.
  • the method may include utilizing the persistent metadata stored in the persistent memory to collect garbage from the persistent memory and to restart the program.
  • the memory allocation module 102 may operate in conjunction with the garbage collection module 110 to utilize the persistent metadata 106 stored in the persistent memory 108 to collect garbage from the persistent memory 108 and to restart the program 104.
  • utilizing the persistent metadata stored in the persistent memory to collect the garbage from the persistent memory and to restart the program may further include collecting the garbage from the persistent memory in an offline mode that is independent of the execution of the program.
  • the method 600 may further include identifying unallocated memory from the persistent memory in a free-list (e.g., the free-list 112) based on the collection of the garbage from the persistent memory, storing the free- list in the persistent metadata, and utilizing the free-list to determine the free-list.
  • a free-list e.g., the free-list 112
  • the method 600 may further include identifying unallocated memory from the persistent memory in a free-list, in response to the determination that the termination of the program is based on the specified termination of the program during the execution of the program, designating the free-list as being consistent, and utilizing the free-list to restart the program.
  • the method 600 may further include identifying unallocated memory from the persistent memory in a free-list, in response to the determination that the termination of the program is based on the unspecified termination of the program during the execution of the program, designating the free-list as being inconsistent, and discarding the free-list.
  • the method 600 may further include generating a new free-list to identify the unallocated memory from the persistent memory in the new free-list, storing the new free-list in the persistent metadata, and utilizing the new free-list to restart the program.
  • the method 600 may further include identifying unallocated memory from the persistent memory in a free-list that includes an object free-list and a page free-list.
  • the object free-list may represent free objects whose size may be less than a memory page of the persistent memory, and the page free-list may represent free memory pages of the persistent memory.
  • the method 600 may further include identifying allocated memory objects within an associated memory page of the persistent memory in headers (e.g., the headers 114), storing the headers in the persistent metadata, and utilizing the headers to determine the allocated memory objects to collect the garbage from the persistent memory and to restart the program.
  • headers e.g., the headers 114
  • the method 600 may further include identifying modifications related to allocation of the persistent memory in a consistency log (e.g., the consistency log 120), storing the consistency log in the persistent metadata, and utilizing the consistency log to determine the modifications related to the allocation of the persistent memory to collect the garbage from the persistent memory and to restart the program.
  • the modifications may include current and previous values related to the allocation of the persistent memory.
  • the method may include determining whether termination of a program is based on a specified termination of the program during execution of the program or an unspecified termination of the program during the execution of the program.
  • the memory allocation module 102 may determine whether termination of the program 104 is based on a specified termination (e.g., an exit during or after program execution, etc.) of the program 104 during execution of the program 104, or an unspecified termination (e.g., process failures, kernel panics, power outages, etc.) of the program 104 during the execution of the program 104.
  • a specified termination e.g., an exit during or after program execution, etc.
  • an unspecified termination e.g., process failures, kernel panics, power outages, etc.
  • the method may include utilizing persistent metadata stored in a persistent memory to restart the program.
  • the memory allocation module 102 may utilize persistent metadata 106 stored in the persistent memory 108 to restart the program 104.
  • the method may include determining an offline mode that is independent from the execution of the program.
  • the memory allocation module 102 may determine an offline mode that is independent from the execution of the program 104.
  • the method may include utilizing the persistent metadata stored in the persistent memory to collect garbage from the persistent memory in the offline mode and to restart the program.
  • the memory allocation module 102 may operate in conjunction with the garbage collection module 110 to utilize the persistent metadata 106 stored in the persistent memory 108 to collect garbage from the persistent memory 108 in an offline mode that is independent of the execution of the program and to restart the program 104.
  • the method 700 may further include storing the persistent metadata in a persistent scratch space of the persistent memory, and isolating the persistent scratch space from the collection of the garbage from the persistent memory.
  • the method 700 may further include identifying unallocated memory from the persistent memory in a free-list, storing the free-list in the persistent metadata, and utilizing the free-list to determine the unallocated memory to collect the garbage from the persistent memory and to restart the program.
  • the method 700 may further include placing mark bits in the persistent memory, updating the mark bits according to a specified procedure, collecting, subsequent to a mark phase, all unmarked objects from the persistent memory, and adding the unmarked objects that are collected to a free-list in the persistent memory.
  • mark bits that indicate whether a particular chunk of the persistent memory 108 is reachable may be maintained in the persistent memory 108.
  • the mark bits may be updated according to a specified procedure (e.g., the mark bits may be updated using failure-atomic CPU instructions).
  • all unmarked objects may be collected from the persistent memory 108, and the unmarked objects that are collected may be added to the free-list 112 in the persistent memory.
  • the method may include identifying unallocated memory from a persistent memory in a free-list included in persistent metadata stored in the persistent memory.
  • the memory allocation module 102 may identify unallocated memory from the persistent memory 108 in the free-list 112 included in persistent metadata 106 stored in the persistent memory 108.
  • the method may include identifying modifications related to allocation of the persistent memory in a consistency log included in the persistent metadata.
  • the memory allocation module 102 may identify modifications related to allocation of the persistent memory 108 in the consistency log 120 included in the persistent metadata 106.
  • the method may include determining whether termination of a program is based on a specified termination of the program during execution of the program or an unspecified termination of the program during the execution of the program.
  • the memory allocation module 102 may determine whether termination of the program 104 is based on a specified termination (e.g., an exit during or after program execution, etc.) of the program 104 during execution of the program 104, or an unspecified termination (e.g., process failures, kernel panics, power outages, etc.) of the program 104 during the execution of the program 104.
  • a specified termination e.g., an exit during or after program execution, etc.
  • an unspecified termination e.g., process failures, kernel panics, power outages, etc.
  • the method may include utilizing persistent metadata stored in a persistent memory to restart the program.
  • the memory allocation module 102 may utilize persistent metadata 106 stored in the persistent memory 108 to restart the program 104.
  • the method may include utilizing the persistent metadata stored in the persistent memory to collect garbage from the persistent memory and to restart the program.
  • the memory allocation module 102 may operate in conjunction with the garbage collection module 110 to utilize the persistent metadata 106 stored in the persistent memory 108 to collect garbage from the persistent memory 108 and to restart the program 104.
  • the method 800 may further include
  • the method 800 may further include
  • Figure 9 shows a computer system 900 that may be used with the examples described herein.
  • the computer system 900 may represent a generic platform that includes components that may be in a server or another computer system.
  • the computer system 900 may be used as a platform for the apparatus 100.
  • the computer system 900 may execute, by a processor (e.g., a single or multiple processors) or other hardware processing circuit, the methods, functions and other processes described herein.
  • a computer readable medium which may be non-transitory, such as hardware storage devices (e.g., RAM (random access memory), ROM (read only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), hard drives, and flash memory).
  • RAM random access memory
  • ROM read only memory
  • EPROM erasable, programmable ROM
  • EEPROM electrically erasable, programmable ROM
  • hard drives e.g., hard drives, and flash memory
  • the computer system 900 may include a processor 902 that may implement or execute machine readable instructions performing some or all of the methods, functions and other processes described herein. Commands and data from the processor 902 may be communicated over a communication bus 904.
  • the computer system may also include a main memory 906, such as a random access memory (RAM), where the machine readable instructions and data for the processor 902 may reside during runtime, and a secondary data storage 908, which may be non-volatile and stores machine readable instructions and data.
  • the memory and data storage are examples of computer readable mediums.
  • the memory 906 may include a persistent memory garbage collection module 920 including machine readable instructions residing in the memory 906 during runtime and executed by the processor 902.
  • the persistent memory garbage collection module 920 may include the modules of the apparatus 100 shown in Figure 1 .
  • the computer system 900 may include an I/O device 910, such as a keyboard, a mouse, a display, etc.
  • the computer system may include a network interface 912 for connecting to a network.
  • Other known electronic components may be added or substituted in the computer system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Memory System (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Selon un mode de réalisation représentatif, la présente invention mémoire concerne la récupération de données superflues de mémoire persistante pouvant comprendre la détermination pour savoir si la fin d'un programme est basée sur une fin spécifiée du programme pendant l'exécution du programme ou une fin non spécifiée du programme pendant l'exécution du programme. En réponse à une détermination que la fin du programme est basée sur la fin spécifiée du programme pendant l'exécution du programme, des métadonnées persistantes stockées dans une mémoire persistante peuvent être utilisées pour redémarrer le programme. En réponse à une détermination que la fin du programme est basée sur la fin non spécifiée du programme pendant l'exécution du programme, les métadonnées persistantes stockées dans la mémoire persistante peuvent être utilisées pour la récupération de données superflues de la mémoire persistante et pour redémarrer le programme.
PCT/US2015/010862 2015-01-09 2015-01-09 Récupération de données superflues de mémoire persistante WO2016111702A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/US2015/010862 WO2016111702A1 (fr) 2015-01-09 2015-01-09 Récupération de données superflues de mémoire persistante
US15/538,377 US10949342B2 (en) 2015-01-09 2015-01-09 Persistent memory garbage collection

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2015/010862 WO2016111702A1 (fr) 2015-01-09 2015-01-09 Récupération de données superflues de mémoire persistante

Publications (1)

Publication Number Publication Date
WO2016111702A1 true WO2016111702A1 (fr) 2016-07-14

Family

ID=56356260

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/010862 WO2016111702A1 (fr) 2015-01-09 2015-01-09 Récupération de données superflues de mémoire persistante

Country Status (2)

Country Link
US (1) US10949342B2 (fr)
WO (1) WO2016111702A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018231476A1 (fr) * 2017-06-15 2018-12-20 Microsoft Technology Licensing, Llc Gestion de mémoire dans une mémoire non volatile
CN109725842A (zh) * 2017-10-30 2019-05-07 伊姆西Ip控股有限责任公司 加速随机写入布局以用于混合存储系统内的桶分配的系统和方法
US10922297B2 (en) 2017-03-01 2021-02-16 Sap Se Garbage collection for in-memory row storage

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10437720B2 (en) 2014-03-12 2019-10-08 Optumsoft, Inc. Deferred destruction for efficient resource reclamation
US10296354B1 (en) * 2015-01-21 2019-05-21 Pure Storage, Inc. Optimized boot operations within a flash storage array
US11947968B2 (en) * 2015-01-21 2024-04-02 Pure Storage, Inc. Efficient use of zone in a storage device
US10114559B2 (en) * 2016-08-12 2018-10-30 International Business Machines Corporation Generating node access information for a transaction accessing nodes of a data set index
CN108733311B (zh) * 2017-04-17 2021-09-10 伊姆西Ip控股有限责任公司 用于管理存储系统的方法和设备
US10754556B2 (en) 2017-06-27 2020-08-25 International Business Machines Corporation Prioritization of virtual volumes to take offline in a thin provisioning system
CN112114750B (zh) * 2020-09-11 2023-01-10 苏州浪潮智能科技有限公司 一种元数据卷位图数据冲突处理方法及相关组件
CN112084032B (zh) * 2020-09-15 2023-04-11 电子科技大学 一种写优化的持久性内存堆管理方法
US11474938B2 (en) * 2021-01-18 2022-10-18 EMC IP Holding Company LLC Data storage system with multiple-size object allocator for disk cache

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060265438A1 (en) * 2005-05-20 2006-11-23 Microsoft Corporation Leveraging garbage collection to dynamically infer heap invariants
US20060294165A1 (en) * 2005-06-10 2006-12-28 International Business Machines Corporation Generational real-time garbage collection
US20070022149A1 (en) * 2005-07-22 2007-01-25 International Business Machines Corporation System and method for concurrent garbage collection
US20070220328A1 (en) * 2006-02-28 2007-09-20 Microsoft Corporation Shutdown recovery
US20090327374A1 (en) * 2008-06-30 2009-12-31 Sun Microsystems, Inc. Method and apparatus for performing concurrent garbage collection

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6938245B1 (en) * 1997-10-29 2005-08-30 Veritas Operating Corporation Interactive debugging system with debug data base system
KR101515525B1 (ko) 2008-10-02 2015-04-28 삼성전자주식회사 메모리 장치 및 메모리 장치의 동작 방법
EP2612443A1 (fr) * 2010-09-03 2013-07-10 Loglogic, Inc. Compression de données à accès direct
JP5618796B2 (ja) * 2010-12-02 2014-11-05 株式会社日立製作所 計算機、計算機の制御方法及びプログラム
US9355023B2 (en) * 2011-03-15 2016-05-31 Anirudh Badam Virtual address pager and method for use with a bulk erase memory
WO2013100935A1 (fr) 2011-12-28 2013-07-04 Intel Corporation Procédé et dispositif d'augmentation d'une mémoire volatile dans un sous-système graphique à mémoire non volatile
US20140115291A1 (en) * 2012-10-19 2014-04-24 Advanced Micro Devices, Inc. Numa optimization for garbage collection of multi-threaded applications
CN104937562B (zh) 2013-01-30 2018-04-06 慧与发展有限责任合伙企业 非易失性存储器写入机制
US10073626B2 (en) 2013-03-15 2018-09-11 Virident Systems, Llc Managing the write performance of an asymmetric memory system
US9355029B2 (en) * 2013-06-28 2016-05-31 Sap Se Thread-based memory management with garbage collection
US9430396B2 (en) * 2014-12-22 2016-08-30 Intel Corporation Updating persistent data in persistent memory-based storage

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060265438A1 (en) * 2005-05-20 2006-11-23 Microsoft Corporation Leveraging garbage collection to dynamically infer heap invariants
US20060294165A1 (en) * 2005-06-10 2006-12-28 International Business Machines Corporation Generational real-time garbage collection
US20070022149A1 (en) * 2005-07-22 2007-01-25 International Business Machines Corporation System and method for concurrent garbage collection
US20070220328A1 (en) * 2006-02-28 2007-09-20 Microsoft Corporation Shutdown recovery
US20090327374A1 (en) * 2008-06-30 2009-12-31 Sun Microsystems, Inc. Method and apparatus for performing concurrent garbage collection

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10922297B2 (en) 2017-03-01 2021-02-16 Sap Se Garbage collection for in-memory row storage
WO2018231476A1 (fr) * 2017-06-15 2018-12-20 Microsoft Technology Licensing, Llc Gestion de mémoire dans une mémoire non volatile
US10891221B2 (en) 2017-06-15 2021-01-12 Microsoft Technology Licensing, Llc Memory management in non-volatile memory
EP4113309A1 (fr) * 2017-06-15 2023-01-04 Microsoft Technology Licensing, LLC Gestion de mémoire dans une mémoire non volatile
CN109725842A (zh) * 2017-10-30 2019-05-07 伊姆西Ip控股有限责任公司 加速随机写入布局以用于混合存储系统内的桶分配的系统和方法

Also Published As

Publication number Publication date
US20170351606A1 (en) 2017-12-07
US10949342B2 (en) 2021-03-16

Similar Documents

Publication Publication Date Title
US10949342B2 (en) Persistent memory garbage collection
Wang et al. Easy lock-free indexing in non-volatile memory
US10691559B2 (en) Persistent memory transactions with undo logging
Park et al. {iJournaling}:{Fine-Grained} Journaling for Improving the Latency of Fsync System Call
Hu et al. {Log-Structured}{Non-Volatile} Main Memory
US10909030B2 (en) Enhanced trim command support for solid state drives
US6470436B1 (en) Eliminating memory fragmentation and garbage collection from the process of managing dynamically allocated memory
Kim et al. Fully automatic stream management for {Multi-Streamed}{SSDs} using program contexts
Cai et al. Understanding and optimizing persistent memory allocation
US7469324B2 (en) System and method for concurrent compacting self pacing garbage collection using loaded value and access barriers
US8453015B2 (en) Memory allocation for crash dump
US7587566B2 (en) Realtime memory management via locking realtime threads and related data structures
US20070234296A1 (en) Software variation for robustness through randomized execution contexts
US20130212321A1 (en) Apparatus, System, and Method for Auto-Commit Memory Management
CN105320567B (zh) 用于有效资源回收的延迟损毁
US20160350015A1 (en) Enforcing Persistency for Battery-Backed Mobile Devices
US6523141B1 (en) Method and apparatus for post-mortem kernel memory leak detection
EP3198448B1 (fr) Migration d'une mémoire d'objets assistée par le matériel
US20060248103A1 (en) Method of detecting memory leaks in software applications
US10318198B2 (en) Optimizable heap for embedded and similar systems with enhanced debugging and self-healing
US9727256B1 (en) Virtual memory management techniques
KR20140147017A (ko) 라이트 백 캐싱 환경에서 예상하지 못한 셧다운으로부터 복구하기 위한 시스템 및 방법
Pfähler et al. Formal specification of an erase block management layer for flash memory
Xu et al. FFCCD: fence-free crash-consistent concurrent defragmentation for persistent memory
US10417121B1 (en) Monitoring memory usage in computing devices

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15877261

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15538377

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15877261

Country of ref document: EP

Kind code of ref document: A1