WO2024049487A1 - Differential collection of cyclic memory garbage - Google Patents

Differential collection of cyclic memory garbage Download PDF

Info

Publication number
WO2024049487A1
WO2024049487A1 PCT/US2022/079941 US2022079941W WO2024049487A1 WO 2024049487 A1 WO2024049487 A1 WO 2024049487A1 US 2022079941 W US2022079941 W US 2022079941W WO 2024049487 A1 WO2024049487 A1 WO 2024049487A1
Authority
WO
WIPO (PCT)
Prior art keywords
cycle
memory
memory object
buffer
unlikely
Prior art date
Application number
PCT/US2022/079941
Other languages
French (fr)
Inventor
Jun Wang
Zongfang LIN
Original Assignee
Futurewei Technologies, Inc.
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 Futurewei Technologies, Inc. filed Critical Futurewei Technologies, Inc.
Priority to PCT/US2022/079941 priority Critical patent/WO2024049487A1/en
Publication of WO2024049487A1 publication Critical patent/WO2024049487A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management
    • G06F12/0253Garbage collection, i.e. reclamation of unreferenced memory
    • G06F12/0261Garbage collection, i.e. reclamation of unreferenced memory using reference counting

Definitions

  • the present disclosure is related to techniques associated with electronic device memory, and in particular, to techniques for memory management.
  • Programming languages may use automatic memory management (e.g., garbage memory collection) to remove references (e.g., pointers) to portions of memory that are no longer needed.
  • garbage memory collection may be used to relieve programmers of the burden of explicit memory management at the program level.
  • Garbage memory collection algorithms may include reference counting algorithms and tracing algorithms.
  • reference counting algorithms each memory object may maintain a count of direct references to it from other objects. This count is referred to as the memory object’s reference count (RC).
  • RC reference count
  • the RC of a memory object can change dynamically. When the RC becomes zero, the program no longer references that memory object, so that memory object is considered a garbage memory object and its memory may be reclaimed.
  • Memory tracing algorithms manage memory by placing a program operation on hold and tracing memory to identify garbage memory objects. This is in contrast with reference counting memory collection, which provides memory management and garbage memory removal throughout program execution. Reference counting memory collection algorithms enable the program to run more smoothly, which may be desirable in applications in which the program responsiveness is important.
  • a method for computer-implemented memory reclamation including: scanning a first memory object within a cycle-likely buffer; reclaiming a device memory location associated with the first memory object if the first memory object is part of a first garbage cycle; determining whether a cycle-unlikely buffer should be scanned; scanning a second memory object within the cycle-unlikely buffer; and reclaiming a device memory location associated with the second memory object if the second memory object is part of a second garbage cycle.
  • scanning the cycle -unlikely buffer occurs less frequently than scanning the cycle-likely buffer.
  • the method further includes determining the first memory object is not part of the first garbage cycle; and storing the first memory object within the cycle-unlikely buffer.
  • the method further includes marking a first memory type of the first memory object as cycle -unlikely in response to a determination that the first memory object is not part of the first garbage cycle; and storing the first memory object within the cycle-unlikely buffer.
  • the method further includes determining the first memory object is part of the first garbage cycle.
  • the method further includes marking a first memory type of the first memory object as cycle-likely in response to a determination that the first memory object is part of the first garbage cycle.
  • the second garbage cycle includes a pair of mutual references between the second memory object and a third memory object.
  • the second garbage cycle includes the pair of mutual references without an external memory pointer associated with either the second memory object or the third memory object.
  • the method further includes decrementing a reference count of the third memory object.
  • the method further includes determining the reference count is greater than zero; determining whether the third memory object is cycle- likely or cycle-unlikely; adding the third memory object to the cycle-likely buffer or the cycle-unlikely buffer; and marking the third memory object to indicate the third memory object is stored in the cycle-likely buffer or the cycle- unlikely buffer.
  • marking the first memory object includes changing an object header bit flag or storing a hash table entry.
  • the method further includes determining the reference count is zero; and releasing the third memory object.
  • the method further comprising removing the first memory object from the cycle-likely buffer in response to determining the first memory object is part of the first garbage cycle.
  • the method further comprising removing the second memory object from the cycle -unlikely buffer in response to determining the second memory object is part of the second garbage cycle.
  • the determining whether the cycle-unlikely buffer should be scanned comprising determining whether a current collection number C is a multiple of a cycle-unlikely frequency U.
  • a system for computer- implemented memory reclamation including: a memory storing instructions; a cycle-likely buffer; a cycle-unlikely buffer; at least one processor in communication with the memory, the cycle-likely buffer, and the cycle- unlikely buffer, the at least one processor configured, upon execution of the instructions, to perform the following steps: scan a first memory object within the cycle-likely buffer; reclaim a device memory location associated with the first memory object if the first memory object is part of a first garbage cycle; determine whether a cycle-unlikely buffer should be scanned; scan a second memory object within the cycle-unlikely buffer; and reclaim a device memory location associated with the second memory object if the second memory object is part of a second garbage cycle.
  • the processing circuitry further executes the instructions to determine the first memory object is not part of the first garbage cycle; and stores the first memory object within the cycle-unlikely memory buffer.
  • the processing circuitry further marks a first memory type of the first memory object as cycle -unlikely in response to a determination that the first memory object is not part of the first garbage cycle; and stores the first memory object within the cycle -unlikely memory buffer.
  • the second garbage cycle includes a pair of mutual references between the second memory object and a third memory object.
  • the second garbage cycle includes the pair of mutual references without an external memory pointer associated with either the second memory object or the third memory object.
  • the processing circuitry further executes the instructions to decrement a reference count of the third memory object.
  • the processing circuitry further executes the instructions to determine whether the third memory object is cycle-likely or cycle -unlikely and add the third memory object to the cycle-likely memory buffer or the cycle- unlikely memory buffer; and mark the third memory object to indicate the third memory object is stored in the cycle-likely buffer or the cycle -unlikely buffer.
  • marking the first memory object includes changing an object header bit flag or storing a hash table entry.
  • the processing circuitry further to determine the reference count is zero; and release the third memory object.
  • the determining whether the cycle-unlikely buffer should be scanned comprising determining whether a current collection number C is a multiple of a cycle-unlikely frequency U.
  • At least one non-transitory machine-readable storage medium including scanning a first memory object within a cycle-likely buffer; reclaiming a device memory location associated with the first memory object if the first memory object is part of a first garbage cycle; determining whether a cycle-unlikely buffer should be scanned; scanning a second memory object within the cycle-unlikely buffer; and reclaiming a device memory location associated with the second memory object if the second memory object is part of a second garbage cycle.
  • a non-transitory computer- readable storage media wherein scanning the cycle -unlikely buffer occurs less frequently than scanning the cycle-likely buffer.
  • an at least one non-transitory machine-readable storage medium the instructions further causing the processor circuitry to determine the first memory object is not part of the first garbage cycle; and store the first memory object within the cycle -unlikely buffer.
  • an at least one non-transitory machine-readable storage medium the instructions further causing the processor circuitry to mark a first memory type of the first memory object as cycle- unlikely in response to a determination that the first memory object is not part of the first garbage cycle; and store the first memory object within the cycle- unlikely buffer.
  • an at least one non-transitory machine-readable storage medium wherein the second garbage cycle includes a pair of mutual references between the second memory object and a third memory object.
  • the second garbage cycle includes the pair of mutual references without an external memory pointer being associated with either the second memory object or the third memory object.
  • the instructions further causing the at least one processor to decrement a reference count of the third memory object.
  • the instructions further causing the at least one processor to: determine the reference count is greater than zero; determine whether the third memory object is cycle-likely or cycle -unlikely and add the third memory object to the cycle-likely buffer or the cycle-unlikely buffer; and mark the third memory object to indicate the third memory object is stored in the cycle-likely buffer or the cycle -unlikely buffer.
  • marking the first memory object includes changing an object header bit flag or storing a hash table entry.
  • the instructions further causing the at least one processor to: determine the reference count is zero; and release the third memory object.
  • the instructions further causing the at least one processor to remove the first memory object from the cycle-likely buffer in response to determining the first memory object is part of the first garbage cycle.
  • the instructions further causing the at least one processor to remove the second memory object from the cycle -unlikely buffer in response to determining the second memory object is part of the second garbage cycle.
  • the determining whether the cycle-unlikely buffer should be scanned comprising determining whether a current collection number C is a multiple of a cycle-unlikely frequency U.
  • FIGs. 1A-1D are block diagrams illustrating memory heap snapshots, according to an example embodiment.
  • FIGs. 2A-2D are block diagrams illustrating a memory cycle, according to an example embodiment.
  • FIGs. 3A-3C are block diagrams illustrating a memory cycle scan, according to an example embodiment.
  • FIG. 4 is a block diagram illustrating a memory garbage cycle collection, according to an example embodiment.
  • FIG. 5 is a flowchart illustrating a memory garbage cycle collection method, according to an example embodiment.
  • Fig. 6 is a flowchart illustrating a memory garbage cycle collection method according to another embodiment.
  • FIG. 7 is a flowchart illustrating a memory buffer allocation method, according to an example embodiment.
  • FIG. 8 is a flowchart illustrating a method for computer- implemented memory reclamation, according to an example embodiment.
  • FIG. 9 is a block diagram illustrating a representative software architecture, which may be used in conjunction with various device hardware described herein, according to some example embodiments.
  • FIG. 10 is a block diagram illustrating circuitry for a device that implements algorithms and performs methods, according to some example embodiments.
  • the functions or algorithms described herein may be implemented in software in one embodiment.
  • the software may consist of computer-executable instructions stored on computer-readable media or a computer-readable storage device such as one or more non-transitory memories or other types of hardware -based storage devices, either local or networked.
  • modules which may be software, hardware, firmware, or any combination thereof. Multiple functions may be performed in one or more modules as desired, and the embodiments described are merely examples.
  • the software may be executed on a digital signal processor, ASIC, microprocessor, or another type of processor operating on a computer system, such as a personal computer, server, or another computer system, turning such computer system into a specifically programmed machine.
  • FIG. 1A-1D are block diagrams illustrating memory heap snapshots 100, according to an example embodiment.
  • the first memory heap snapshot 110 includes a memory object X that is created on the memory heap and assigned to first pointer Pl.
  • a memory object describes a block or region of memory that is used to store information for later retrieval and use.
  • the RC in this example comprises a reference count associated with the memory object X.
  • Each such memory object can have an associated RC.
  • a second pointer P2 is also assigned to the address associated with memory object X, this increases the RC to 2.
  • the first memory pointer Pl is reassigned to an address that is not associated with memory object X, which decreases the RC to 1.
  • the second memory pointer P2 is also reassigned to an address that is not associated with memory object X, which decreases the RC to 0.
  • the memory object X represents a memory region that can be reclaimed (e.g., garbage memory that can be recycled).
  • FIGs. 2A-2D are block diagrams illustrating formation of a memory cycle 200, according to an example embodiment.
  • the first memory object VS and the second memory object VT point to each other, but neither is referenced by external pointer.
  • both memory objects have RC > 0, but form a self-referential garbage memory cycle.
  • a memory management scheme may be improved by addressing such a garbage reference cycle to identify and reclaim memory objects that have RC > 0 but are not referenced by an external pointer. Reclaiming these memory regions may include marking each memory region (e.g., device memory location) as available for use, erasing that memory region, storing new data within that memory region, and other memory operations consistent with available memory regions.
  • FIG. 3A-3C are block diagrams illustrating a memory cycle scan 300, according to an example embodiment.
  • FIG. 3 A shows an initial state 310 of a group of memory objects.
  • Memory object A 315 and memory object B 325 reference each other, and form a memory reference cycle.
  • Memory object C 335 is referenced by memory object B 325 and by memory object Y 340.
  • memory object D 345 is referenced by memory object C 335 and by memory object Z 350.
  • FIG. 3B shows a memory cycle candidate identification state 320.
  • memory object A 315 is identified as a potential memory reference cycle candidate.
  • the descendent memory objects e.g., pointer-based downstream memory objects
  • the descendant memory objects B, C, and D are visited and marked as downstream memory objects.
  • FIG. 3C shows a memory scanning state 320, where each descendent memory object is scanned to determine whether it is referenced by another memory object.
  • the scan identifies that memory object C 335 is referenced by memory object Y 340, and that memory object D 345 is referenced by memory object Z 350. This indicates that memory object C 335 and memory object D 345 should not be reclaimed, but that memory object A 315 and memory object B 325 form a garbage memory cycle and may be removed.
  • FIG. 4 is a block diagram illustrating a differential memory garbage cycle collection system 400, according to an example embodiment.
  • This memory garbage cycle collection system 400 may be used to identify and store memory objects as cycle-likely or cycle-unlikely, and any stored memory objects that are identified as garbage memory cycle regions may be reclaimed.
  • the memory garbage cycle collection system 400 provides improved memory management by separating memory cycle candidates into at least two buffers.
  • the memory cycle candidates may include cycle-likely data type memory objects that are likely to be included as part of a garbage memory cycle, and may include cycle -unlikely data type memory objects that are unlikely to be included as part of a garbage memory cycle.
  • Each of these memory cycle candidates may be held within a corresponding buffer within buffers 405.
  • Buffers 405 may include two or more data buffers, where each data buffer is a region of a memory used for non-permanent data storage.
  • buffers 405 include a cycle-likely buffer 410 (e.g., likely buffer) that holds cycle-likely data type memory objects, and include a cycle-unlikely buffer 415 (e.g., unlikely buffer) that holds cycle -unlikely data type memory objects.
  • a memory cycle garbage collector 420 may be used to collect cycle-garbage from the cycle-likely buffer 410 and from the cycle -unlikely buffer 415.
  • the collection of cycle-garbage from the cycle- unlikely buffer 415 may include using the memory cycle scan 300. These memory collections may be performed periodically (e.g., a lazy local-scan), such as in response to the expiration of a predetermined scan delay period.
  • a different collection period e.g., collection frequency
  • the cycle-likely buffer 410 is scanned more frequently than the cycle-unlikely buffer 415.
  • memory objects in the cycle-likely buffer 410 are scanned every time the system scans for cycles (e.g., every collection cycle), but memory objects in the cycle-unlikely buffer 415 are scanned less frequently (e.g., every two or three collections, for example, depending on the multiple M).
  • Scanning the cycle -unlikely buffer 415 less frequently provides various advantages.
  • This reduced scanning frequency for the cycle-unlikely buffer 415 reduces the average number of scanned candidates per collection, resulting in a shorter pause time during scanning.
  • This modified scanning frequency also reduces the overall number of scanned candidates, resulting in a reduced computation overhead for garbage memory collection.
  • memory objects that are not part of garbage memory cycles have a greater possibility of being identified as reclaimable garbage memory and being removed from the buffers 405 before they are scanned. By removing (noncycle) memory objects from the buffers 405 before they are scanned, fewer memory objects are scanned, further reducing the total computation overhead for garbage memory collection. This provides a further improvement on the memory cycle scan 300 by reducing or avoiding the need to scan all descendants of a memory cycle candidate multiple times.
  • each memory object may have its associated cycle-likeness information 430 stored in a memory.
  • the cycle-likeness information may include the use of one or more data structures to indicate whether the memory object is cycle-likely or cycle-unlikely. If the computing system supports datatype objects (e.g., a data type represented by a special object), a binary bit may be stored in the object header or within the type object itself, and may be used as a flag to indicate cycle-like liness of the data type.
  • a hash table may also be used to hold data types that are associated with each memory object. As a result, the cycle- likeliness information can be applied to objects of a same object type.
  • a runtime RC system 440 may be used to monitor pointers and increase or decrease the RC for each memory object. When the runtime RC system 440 decreases the RC for a memory object, that memory object may be added to cycle-likely buffer 410 or to the cycle -unlikely buffer 415, based on the associated cycle-likeness information 430 stored in memory.
  • cycle-likely buffer 410 in some embodiments is scanned more often than the cycle-unlikely buffer 415.
  • a memory object can be retained in the cycle-likely buffer 410 for one or more garbage memory collection iterations, including for an iteration or iterations after the object is initially added to the cycle-likely buffer 410.
  • each object is given a reference count (RC).
  • RC reference count
  • a new pointer is added for a particular object, its RC is incremented.
  • an existing pointer is removed, the RC is decremented.
  • the RC for the particular object is decremented down to zero, the particular object becomes garbage, and the memory allocated to the particular object is reclaimed.
  • a garbage cycle can comprise two objects, or more than two objects.
  • the RC of a memory object can be incremented or decremented upon a change to the memory object.
  • the RC can be updated at regular or irregular intervals, such as periodically, per each processing loop, or according to other criteria.
  • the updating of RC values does not necessarily coincide with garbage collection times.
  • a particular garbage collection time operates on RC values existing at that time, and according to a scan of the cycle- likely buffer 410. If the garbage collection time coincides with the time for scanning both the cycle-likely buffer 410 and the cycle-unlikely buffer 415, then a memory object can be maintained in a current buffer or can be moved between buffers.
  • the cycle-likeliness information applies to an object. In other embodiments, the cycle-likeliness information applies to a class or group of objects.
  • the object when an object is to be put into either the cycle-likely buffer or the cycle-unlikely buffer, the object is put into the cycle- likely buffer by default. In other embodiments, the object is put into the cycle- unlikely buffer by default. In yet other embodiments, the object is put into the cycle-unlikely buffer if the object type indicator is not set, and is put into the cycle-likely buffer if the object type indicator is set.
  • the cycle-likeliness information is set when a garbage cycle is detected.
  • the cycle-likeliness information is set during a time when the cycle-likely or cycle -unlikely buffer is scanned.
  • the cycle-likeliness information is typically not cleared when the object is reclaimed.
  • the cycle-likeliness information can be cleared, such as when: 1) a predefined number of garbage collection cycles have passed since the cycle-likeliness information was originally set, 2) a predefined number of garbage collection cycles have passed since the cycle-likeliness information was originally set and the indicator was not determined to still apply since the original setting of the cycle-likeliness information (i.e., the set cycle-likeliness information would have been set at a later time if it had not already been set), 3) a predetermined change has occurred in the corresponding application, or 4) the corresponding object (or object type) has not been created again before expiration of a timer (i.e., a non-use timer for the object or object type begins to run at a last reclamation and the cycle- likeliness information is cleared when the timer expires).
  • a timer i.e., a non-use timer for the object or object type begins to run at a last reclamation and the cycle- likeliness information is cleared when the timer expires.
  • FIG. 5 is a flowchart illustrating a memory garbage cycle collection method 500, according to an example embodiment.
  • the memory garbage cycle collection method 500 shows an example method that may be used with the memory garbage cycle collection system 400.
  • the memory garbage cycle collection method 500 implements the different collection frequencies used by memory cycle garbage collector 420 for each of the cycle- likely buffer and the cycle-unlikely buffer.
  • the memory garbage cycle collection method 500 may be repeated for each collection cycle.
  • a garbage collection operation is begun, with the garbage collection being directed to collection and reclamation of cyclic garbage.
  • the garbage collection is begun depending on stored variables.
  • a variable C may represent the current collection number
  • variable U may represent the number of collection cycles between two successive scans of the cycle-unlikely buffer. It should be understood that the variables C and U are merely one way of setting the times for servicing the cycle-likely buffer and the cycle-unlikely buffer and controlling the frequency of the cycle-likely processing with respect to the cycle-unlikely processing.
  • each memory object in the cycle-likely buffer is scanned for garbage memory cycles.
  • the data type associated with each of the memory objects that is not in a garbage memory cycle is marked as cycle- unlikely.
  • the data type associated with each of the memory objects that is in a garbage memory cycle is marked as cycle-likely.
  • the garbage collection condition comprises whether the current collection number C is a multiple of the cycle-unlikely frequency variable U. If C is a multiple of U, then in this embodiment each object in the cycle-unlikely buffer is scanned at sixth step 560.
  • the garbage collection condition comprises whether the current collection number C is a multiple of the cycle-unlikely frequency variable U. If C is a multiple of U, then in this embodiment each object in the cycle-unlikely buffer is scanned at sixth step 560.
  • seventh step 570 for each object in the cycle-unlikely buffer that is part of a garbage memory cycle, its associated data type is marked as cycle-likely. In an example, when variable U is set to three, then the cycle-unlikely buffer is scanned at sixth step 560 and may be marked at seventh step 570 at every third collection cycle.
  • Example pseudocode associated with memory garbage cycle collection method 500 is shown below:
  • condition 550 in FIG. 5 for scanning the cycle -unlikely buffer is determined at runtime based on historic behavior of the program and/or the garbage collection.
  • condition 550 in FIG. 5 for scanning the cycle-unlikely buffer is that the size of the buffer exceeds a certain size.
  • the size can be pre-determined or changed based on runtime behavior.
  • condition 550 in FIG.5 for scanning the cycle-unlikely buffer is that the amount of available memory is below a certain threshold.
  • the threshold can be pre-determined or changed based on runtime behavior.
  • FIG. 6 is a flowchart illustrating a memory garbage cycle collection method 600 according to another embodiment.
  • first memory object is scanned.
  • the first memory object is reference by the cycle-likely buffer.
  • step 606 it is determined whether the first memory object is within a garbage cycle. If the first memory object is within a garbage cycle, then the method proceeds to step 610. Otherwise, the method branches to step 615.
  • the first memory object is reclaimed. Additionally, the first memory object is removed from the cycle-likely buffer.
  • the cycle-unlikely buffer should be checked in one embodiment when the variable C is a multiple of U.
  • other variables can alternatively control when the cycle-unlikely buffer should be checked.
  • the scan of the cycle-likely buffer may have just been conducted, and now the cycle -unlikely buffer is checked. This occurs when C is a multiple of U, and then both the cycle-likely and the cycle-unlikely buffer are scanned. If the cycle-unlikely buffer should be checked, then the method will proceed to step 617. Otherwise, the method will branch back to step 604 and the monitoring will continue.
  • a second memory object will be scanned.
  • the second memory object is within the cycle -unlikely buffer.
  • step 620 it is determined whether the second memory object is within a garbage cycle. If the second memory object is within a garbage cycle, then the method proceeds to step 623. Otherwise, the method branches back to step 604 and the monitoring will continue.
  • the second memory object is reclaimed. Additionally, the second memory object is removed from the cycle-unlikely buffer.
  • FIG. 7 is a flowchart illustrating a memory buffer allocation method 700, according to an example embodiment.
  • the memory buffer allocation method 700 shows an example method that may be used by the runtime RC system 440 to add a new memory cycle candidate object to the cycle-likely buffer or the cycle-unlikely buffer.
  • the memory object is analyzed to determine whether that memory object is already within a buffer. If that memory object is not within a buffer, at second step 720, the cycle-likeliness information forthat memory object is retrieved.
  • the cycle likeliness information forthat memory object is analyzed to determine whether the object is cycle-likely. If the memory object is cycle-likely, then the object is added to the cycle-likely buffer at step 740. If the memory object is cycle-unlikely, then the object is added to the cycle -unlikely buffer at step 745. Once the memory object has been added to a buffer, the memory object is marked (e.g., in the object header) as having been added to a buffer at step 750. [00102] Memory buffer allocation method 700 may be called in response to a determination that the RC of a memory object has been reduced but remains above zero.
  • FIG. 8 is a flowchart illustrating a method for computer- implemented memory reclamation 800, according to an example embodiment.
  • method 800 includes collecting, at a memory cycle garbage collector, a first memory object from a cycle-likely buffer, and a second memory object from a cycle-unlikely buffer.
  • method 800 includes marking the second memory object as cycle-likely in response to a determination that the second memory object is part of a garbage cycle.
  • method 800 includes determining the second memory object is part of a garbage cycle.
  • method 800 includes reclaiming a device memory location (e.g., computing device memory addresses) associated with the second memory object. Reclaiming the device memory location may include marking the device memory location as available for use, erasing the device memory location, storing new data within the device memory location, or other memory operations consistent with available device memory locations.
  • a device memory location e.g., computing device memory addresses
  • method 800 may include determining the first memory object is not part of the garbage cycle, and storing the first memory object within the cycle-unlikely buffer.
  • method 800 may include marking a first memory type of the first memory object as cycle-unlikely in response to a determination that the first memory object is not part of a garbage cycle, and storing the first memory object within the cycle -unlikely buffer.
  • the garbage cycle includes a pair of mutual references between the second memory object and a third memory object.
  • the garbage cycle includes the pair of mutual references without a memory pointer associated with either the second memory object or the third memory object.
  • method 800 may include decrementing a reference count of a new memory object.
  • method 800 may include determining whether the new memory object is cycle-likely or cycle-unlikely, adding the new memory object to the cycle-likely buffer or the cycle-unlikely buffer, and marking the new memory object to indicate it is stored in a buffer.
  • marking the first memory object as cycle -likely or cycle - unlikely includes changing a memory object header bit flag (e.g., a cycle-likely bit flag or cycle-unlikely bit flag) or storing a hash table entry (e.g., storing a hash of the memory object with an associated cycle-likely flag or cycle-unlikely flag).
  • method 800 may include determining the reference count is zero and releasing the new memory object, thereby freeing the underlying memory region associated with the new memory object.
  • FIG. 9 is a block diagram 900 illustrating a representative software architecture, which may be used in conjunction with various device hardware described herein, according to some example embodiments.
  • FIG. 9 is merely a non-limiting example of a software architecture 902 and it will be appreciated that many other architectures may be implemented to facilitate the functionality described herein.
  • the software architecture 902 may be executing on hardware such as computing device 1000 of FIG. 10 that includes, among other things, processor 1005, memory 1010, storage 1015 and 1020, and I/O interfaces 1025 and 1030.
  • a representative hardware layer 904 is illustrated and can represent, for example, the computing device 1000 of FIG. 10.
  • the representative hardware layer 904 comprises one or more processing units 906 having associated executable instructions 908.
  • Executable instructions 908 represent the executable instructions of the software architecture 902, including implementation of the methods, modules, and so forth of FIGs. 1-2.
  • Hardware layer 904 also includes memory and/or storage modules 910, which also have executable instructions 908.
  • Hardware layer 904 may also comprise other hardware 912, which represents any other hardware of the hardware layer 904, such as the other hardware illustrated as part of computing device 1000.
  • the software architecture 902 may be conceptualized as a stack of layers where each layer provides particular functionality.
  • the software architecture 902 may include layers such as an operating system 914, libraries 916, frameworks/middleware 918, applications 920, and presentation layer 944.
  • the applications 920 and/or other components within the layers may invoke application programming interface (API) calls 924 through the software stack and receive a response, returned values, and so forth illustrated as messages 926 in response to the API call 924.
  • API application programming interface
  • the layers illustrated in FIG. 9 are representative in nature and not all software architectures 902 have all layers. For example, some mobile or special purpose operating systems may not provide frameworks/middleware 918, while others may provide such a layer. Other software architectures may include additional or different layers.
  • the operating system 914 may manage hardware resources and provide common services.
  • the operating system 914 may include, for example, a kernel 928, services 930, and drivers 932.
  • the kernel 928 may act as an abstraction layer between the hardware and the other software layers. For example, kernel 928 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and so on.
  • the services 930 may provide other common services for the other software layers.
  • the drivers 932 may be responsible for controlling or interfacing with the underlying hardware.
  • the drivers 932 may include display drivers, camera drivers, Bluetooth® drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, audio drivers, power management drivers, and so forth, depending on the hardware configuration.
  • serial communication drivers e.g., Universal Serial Bus (USB) drivers
  • USB Universal Serial Bus
  • Wi-Fi® drivers audio drivers
  • power management drivers and so forth, depending on the hardware configuration.
  • the libraries 916 may provide a common infrastructure that may be utilized by the applications 920 and/or other components and/or layers.
  • the libraries 916 typically provide functionality that allows other software modules to perform tasks more easily than to interface directly with the underlying operating system 914 functionality (e.g., kernel 928, services 930, and drivers 932).
  • the libraries 916 may include system libraries 934 (e.g., C standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like.
  • the libraries 916 may include API libraries 936 such as media libraries (e.g., libraries to support presentation and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g., an OpenGU framework that may be used to render 2D and 3D in a graphic content on a display), database libraries (e.g., SQUite that may provide various relational database functions), web libraries (e.g., WebKit that may provide web browsing functionality), and the like.
  • the libraries 916 may also include a wide variety of other libraries 938 to provide many other APIs to the applications 920 and other software components/modules.
  • the frameworks/middleware 918 may provide a higher-level common infrastructure that may be utilized by the applications 920 and/or other software components/modules.
  • the frameworks/middleware 918 may provide various graphical user interface (GUI) functions, high-level resource management, high-level location services, and so forth.
  • GUI graphical user interface
  • the frameworks/middleware 918 may provide a broad spectrum of other APIs that may be utilized by the applications 920 and/or other software components/modules, some of which may be specific to a particular operating system 914 or platform.
  • the applications 920 include built-in applications 940, third-party applications 942, and container module 960.
  • the container module 960 can include an application. Examples of representative built-in applications 940 may include but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and/or a game application. Third-party applications 942 may include any of the built-in applications 940 as well as a broad assortment of other applications.
  • the third-party application 942 may be mobile software running on a mobile operating system such as iOSTM, AndroidTM, Windows® Phone, or other mobile operating systems.
  • the third-party application 942 may invoke the API calls 924 provided by the mobile operating system such as operating system 914 to facilitate the functionality described herein.
  • the applications 920 may utilize built-in operating system functions (e.g., kernel 928, services 930, and drivers 932), libraries (e.g., system libraries 934, API libraries 936, and other libraries 938), and frameworks/middleware 918 to create user interfaces to interact with users of the system.
  • built-in operating system functions e.g., kernel 928, services 930, and drivers 932
  • libraries e.g., system libraries 934, API libraries 936, and other libraries 938
  • frameworks/middleware 918 e.g., frameworks/middleware 918 to create user interfaces to interact with users of the system.
  • interactions with a user may occur through a presentation layer, such as presentation layer 944.
  • the application/module “logic” can be separated from the aspects of the application/module that interact with a user.
  • Some software architectures utilize virtual machines.
  • virtual machine 948 A virtual machine creates a software environment where applications/modules can execute as if they were executing on a hardware machine (such as the computing device 1000 of FIG. 10, for example).
  • a virtual machine 948 is hosted by a host operating system (operating system 914 in FIG. 9) and typically, although not always, has a virtual machine monitor 946, which manages the operation of the virtual machine 948 as well as the interface with the host operating system (i.e., operating system 914).
  • a software architecture 902 executes within the virtual machine 948 such as an operating system 950, libraries 952, frameworks/middleware 954, applications 956, and/or presentation layer 958. These layers of software architecture executing within the virtual machine 948 can be the same as corresponding layers previously described or may be different.
  • FIG. 10 is a block diagram 1000 illustrating circuitry for a device that implements algorithms and performs methods, according to some example embodiments. All components need not be used in various embodiments. For example, clients, servers, and cloud-based network devices may each use a different set of components, or in the case of servers, larger storage devices.
  • One example computing device in the form of a computer 1000 may include a processor 1005, memory 1010, a removable storage 1015, a non-removable storage 1020, an input interface 1025, an output interface 1030, and a communication interface 1035, all connected by a bus 1040.
  • the example computing device is illustrated and described as the computer 1000, the computing device may be in different forms in different embodiments.
  • the memory 1010 may include volatile memory 1045 and nonvolatile memory 1050 and may store a program 1055.
  • the computer 1000 may include or have access to a computing environment that includes a variety of computer-readable media, such as the volatile memory 1045, the non-volatile memory 1050, the removable storage 1015, and the non-removable storage 1020.
  • the memory 1010 includes random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD ROM), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium capable of storing computer-readable instructions.
  • RAM random-access memory
  • ROM read-only memory
  • EPROM erasable programmable read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory or other memory technologies
  • compact disc read-only memory (CD ROM), digital versatile disks (DVD) or other optical disk storage magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium capable of storing computer-readable instructions.
  • Computer-readable instructions stored on a computer-readable medium are executable by the processor 1005 of the computer 1000.
  • Program 1055 may utilize one or more modules discussed herein.
  • a hard drive, CD-ROM, and RAM are some examples of articles including a non-transitory computer-readable medium such as a storage device.
  • the terms “computer-readable medium” and “storage device” do not include carrier waves to the extent that carrier waves are deemed too transitory.
  • “Computer-readable non-transitory media” includes all types of computer-readable media, including magnetic storage media, optical storage media, flash media, and solid-state storage media. It should be understood that software can be installed on and sold with a computer.
  • the software can be obtained and loaded into the computer, including obtaining the software through a physical medium or distribution system, including, for example, from a server owned by the software creator or from a server not owned but used by the software creator.
  • the software can be stored on a server for distribution over the Internet, for example.
  • the terms “computer-readable medium” and “machine-readable medium” are interchangeable.
  • the computer 1000 includes means for retrieving application data from a computing device of the plurality of computing devices, the application data including an application identification (ID), and a first application version number of an application executing on the computing device.
  • the computer 1000 further includes means for updating a first database table using object type information associated with the application ID and the first application version number, the object type information identifying a database table schema of a data object used by the application, and a plurality of data fields of the data object.
  • the computer 1000 further includes means for synchronizing the data object using synchronization data for the plurality of data fields received from the second computing device to generate a synchronized data object.
  • the computer 1000 further includes means for receiving a second application version number from a second computing device, the second application version number associated with the application executing on the second computing device, in response to a notification of the synchronized data object communicated to the second computing device.
  • the computer 1000 further includes means for selecting one or more of the plurality of data fields of the synchronized data object, based on the second application version number, and means for communicating data stored by the one or more of the plurality of data fields to the third computing device for synchronization.
  • the computer 1000 may include other or additional modules for performing any one or combination of steps described in the embodiments. Further, any of the additional or alternative embodiments or aspects of the method, as shown in any of the figures or recited in any of the claims, are also contemplated to include similar modules.
  • Any one or more of the modules described herein may be implemented using hardware (e.g., a processor of a machine, an applicationspecific integrated circuit (ASIC), field-programmable gate array (FPGA), or any suitable combination thereof). Moreover, any two or more of these modules may be combined into a single module, and the functions described herein for a single module may be subdivided among multiple modules. Furthermore, according to various example embodiments, modules described herein as being implemented within a single machine, database, or device may be distributed across multiple machines, databases, or devices.
  • hardware e.g., a processor of a machine, an applicationspecific integrated circuit (ASIC), field-programmable gate array (FPGA), or any suitable combination thereof.
  • ASIC applicationspecific integrated circuit
  • FPGA field-programmable gate array
  • software including one or more computer-executable instructions that facilitate processing and operations as described above concerning any one or all of the steps of the disclosure can be installed in and sold with one or more computing devices consistent with the disclosure.
  • the software can be obtained and loaded into one or more computing devices, including obtaining software through a physical medium or distribution system, including, for example, from a server owned by the software creator or from a server not owned but used by the software creator.
  • the software can be stored on a server for distribution over the Internet, for example.
  • the components of the illustrative devices, systems, and methods employed per the illustrated embodiments can be implemented, at least in part, in digital electronic circuitry, analog electronic circuitry, computer hardware, firmware, software, or combinations of them. These components can be implemented, for example, as a computer program product such as a computer program, program code, or computer instructions tangibly embodied in an information carrier, or a machine -readable storage device, for execution by, or to control the operation of, data processing apparatus such as a programmable processor, a computer, or multiple computers.
  • a computer program product such as a computer program, program code, or computer instructions tangibly embodied in an information carrier, or a machine -readable storage device, for execution by, or to control the operation of, data processing apparatus such as a programmable processor, a computer, or multiple computers.
  • a computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or another unit suitable for use in a computing environment.
  • a computer program can be deployed to be executed on one computer or multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
  • functional programs, codes, and code segments for accomplishing the techniques described herein can be easily construed as within the scope of the claims by programmers skilled in the art to which the techniques described herein pertain.
  • Method steps associated with the illustrative embodiments can be performed by one or more programmable processors executing a computer program, code, or instructions to perform functions (e.g., by operating on input data and/or generating an output). Method steps can also be performed by, and apparatus for performing the methods can be implemented as, special purpose logic circuitry, e.g., an FPGA (field-programmable gate array) or an ASIC (application-specific integrated circuit), for example.
  • FPGA field-programmable gate array
  • ASIC application-specific integrated circuit
  • a general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine.
  • a processor may also be implemented as a combination of computing devices, e.g. , a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
  • processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer.
  • a processor will receive instructions and data from a read-only memory or a random-access memory, or both.
  • the required elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data.
  • a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks.
  • Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile or non-transitory memory, including by way of example, semiconductor memory devices, e.g., electrically programmable read-only memory or ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory devices, and data storage disks (e.g., magnetic disks, internal hard disks, removable disks, magneto-optical disks, CD-ROM disks or DVD-ROM disks).
  • semiconductor memory devices e.g., electrically programmable read-only memory or ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory devices, and data storage disks (e.g., magnetic disks, internal hard disks, removable disks, magneto-optical disks, CD-ROM disks or DVD-ROM disks).
  • EPROM electrically programmable read-only memory
  • EEPROM electrically erasable programmable ROM
  • flash memory devices e.g., electrical
  • machine-readable medium means a device able to store instructions and data temporarily or permanently and may include, but is not limited to, randomaccess memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage (e.g., Erasable Programmable Read-Only Memory (EEPROM)), and/or any suitable combination thereof.
  • RAM randomaccess memory
  • ROM read-only memory
  • buffer memory flash memory
  • optical media magnetic media
  • cache memory other types of storage
  • EEPROM Erasable Programmable Read-Only Memory
  • machine -readable medium should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store processor instructions.
  • machine-readable medium shall also be taken to include any medium (or a combination of multiple media) that is capable of storing instructions for execution by one or more processors 905, such that the instructions, when executed by one or more processors 905, cause the one or more processors 905 to perform any one or more of the methodologies described herein. Accordingly, a “machine-readable medium” refers to a single storage apparatus or device, as well as “cloud-based” storage systems or storage networks that include multiple storage apparatus or devices. The term “machine- readable medium” as used herein excludes signals per se.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System (AREA)

Abstract

A method and system for computer-implemented memory reclamation is provided. The method includes scanning a first memory object within a cycle-likely buffer (410), reclaiming a device memory location associated with the first memory object if the first memory object is part of a first garbage cycle, determining whether a cycle-unlikely buffer (415) should be scanned, scanning a second memory object within the cycle-unlikely buffer, and reclaiming a device memory location associated with the second memory object if the second memory object is part of a second garbage cycle.

Description

DIFFERENTIAL COLLECTION OF CYCLIC MEMORY GARBAGE
TECHNICAL FIELD
[0001] The present disclosure is related to techniques associated with electronic device memory, and in particular, to techniques for memory management.
BACKGROUND
[0002] Programming languages may use automatic memory management (e.g., garbage memory collection) to remove references (e.g., pointers) to portions of memory that are no longer needed. This garbage memory collection may be used to relieve programmers of the burden of explicit memory management at the program level.
[0003] Garbage memory collection algorithms may include reference counting algorithms and tracing algorithms. In reference counting algorithms, each memory object may maintain a count of direct references to it from other objects. This count is referred to as the memory object’s reference count (RC). As a program proceeds, the RC of a memory object can change dynamically. When the RC becomes zero, the program no longer references that memory object, so that memory object is considered a garbage memory object and its memory may be reclaimed.
[0004] Memory tracing algorithms manage memory by placing a program operation on hold and tracing memory to identify garbage memory objects. This is in contrast with reference counting memory collection, which provides memory management and garbage memory removal throughout program execution. Reference counting memory collection algorithms enable the program to run more smoothly, which may be desirable in applications in which the program responsiveness is important.
SUMMARY
[0005] Various examples are now described to introduce a selection of concepts in a simplified form that is further described below in the detailed description. The Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. [0006] According to a first aspect of the present disclosure, there is provided a method for computer-implemented memory reclamation, the method including: scanning a first memory object within a cycle-likely buffer; reclaiming a device memory location associated with the first memory object if the first memory object is part of a first garbage cycle; determining whether a cycle-unlikely buffer should be scanned; scanning a second memory object within the cycle-unlikely buffer; and reclaiming a device memory location associated with the second memory object if the second memory object is part of a second garbage cycle..
[0007] In some aspects of the method for computer-implemented memory reclamation, scanning the cycle -unlikely buffer occurs less frequently than scanning the cycle-likely buffer.
[0008] In some aspects of the method for computer-implemented memory reclamation, the method further includes determining the first memory object is not part of the first garbage cycle; and storing the first memory object within the cycle-unlikely buffer.
[0009] In some aspects of the method for computer-implemented memory reclamation, the method further includes marking a first memory type of the first memory object as cycle -unlikely in response to a determination that the first memory object is not part of the first garbage cycle; and storing the first memory object within the cycle-unlikely buffer.
[0010] In some aspects of the method for computer-implemented memory reclamation, the method further includes determining the first memory object is part of the first garbage cycle.
[0011] In some aspects of the method for computer-implemented memory reclamation, the method further includes marking a first memory type of the first memory object as cycle-likely in response to a determination that the first memory object is part of the first garbage cycle.
[0012] In some aspects of the method for computer-implemented memory reclamation, the second garbage cycle includes a pair of mutual references between the second memory object and a third memory object.
[0013] In some aspects of the method for computer-implemented memory reclamation, the second garbage cycle includes the pair of mutual references without an external memory pointer associated with either the second memory object or the third memory object.
[0014] In some aspects of the method for computer-implemented memory reclamation, the method further includes decrementing a reference count of the third memory object.
[0015] In some aspects of the method for computer-implemented memory reclamation, the method further includes determining the reference count is greater than zero; determining whether the third memory object is cycle- likely or cycle-unlikely; adding the third memory object to the cycle-likely buffer or the cycle-unlikely buffer; and marking the third memory object to indicate the third memory object is stored in the cycle-likely buffer or the cycle- unlikely buffer.
[0016] In some aspects of the method for computer-implemented memory reclamation, marking the first memory object includes changing an object header bit flag or storing a hash table entry.
[0017] In some aspects of the method for computer-implemented memory reclamation, the method further includes determining the reference count is zero; and releasing the third memory object.
[0018] In some aspects of the method for computer-implemented memory reclamation, the method further comprising removing the first memory object from the cycle-likely buffer in response to determining the first memory object is part of the first garbage cycle.
[0019] In some aspects of the method for computer-implemented memory reclamation, the method further comprising removing the second memory object from the cycle -unlikely buffer in response to determining the second memory object is part of the second garbage cycle.
[0020] In some aspects of the method for computer-implemented memory reclamation, the determining whether the cycle-unlikely buffer should be scanned comprising determining whether a current collection number C is a multiple of a cycle-unlikely frequency U.
[0021] In some aspects, there is provided a system for computer- implemented memory reclamation, the system including: a memory storing instructions; a cycle-likely buffer; a cycle-unlikely buffer; at least one processor in communication with the memory, the cycle-likely buffer, and the cycle- unlikely buffer, the at least one processor configured, upon execution of the instructions, to perform the following steps: scan a first memory object within the cycle-likely buffer; reclaim a device memory location associated with the first memory object if the first memory object is part of a first garbage cycle; determine whether a cycle-unlikely buffer should be scanned; scan a second memory object within the cycle-unlikely buffer; and reclaim a device memory location associated with the second memory object if the second memory object is part of a second garbage cycle.
[0022] In some aspects of the system for computer-implemented memory reclamation, wherein scanning the cycle-unlikely memory buffer occurs less frequently than scanning the cycle-likely memory buffer.
[0023] In some aspects of the system for computer-implemented memory reclamation, the processing circuitry further executes the instructions to determine the first memory object is not part of the first garbage cycle; and stores the first memory object within the cycle-unlikely memory buffer.
[0024] In some aspects of the system for computer-implemented memory reclamation, the processing circuitry further marks a first memory type of the first memory object as cycle -unlikely in response to a determination that the first memory object is not part of the first garbage cycle; and stores the first memory object within the cycle -unlikely memory buffer.
[0025] In some aspects of the system for computer-implemented memory reclamation, the second garbage cycle includes a pair of mutual references between the second memory object and a third memory object.
[0026] In some aspects of the system for computer-implemented memory reclamation, the second garbage cycle includes the pair of mutual references without an external memory pointer associated with either the second memory object or the third memory object.
[0027] In some aspects of the system for computer-implemented memory reclamation, the processing circuitry further executes the instructions to decrement a reference count of the third memory object.
[0028] In some aspects of the system for computer-implemented memory reclamation, the processing circuitry further executes the instructions to determine whether the third memory object is cycle-likely or cycle -unlikely and add the third memory object to the cycle-likely memory buffer or the cycle- unlikely memory buffer; and mark the third memory object to indicate the third memory object is stored in the cycle-likely buffer or the cycle -unlikely buffer. [0029] In some aspects of the system for computer-implemented memory reclamation, marking the first memory object includes changing an object header bit flag or storing a hash table entry.
[0030] In some aspects of the system for computer-implemented memory reclamation, the processing circuitry further to determine the reference count is zero; and release the third memory object.
[0031] In some aspects of the system for computer-implemented memory reclamation, further comprising the processing circuitry executing the instructions to remove the first memory object from the cycle-likely buffer in response to determining the first memory object is part of the first garbage cycle. [0032] In some aspects of the system for computer-implemented memory reclamation, further comprising the processing circuitry executing the instructions to remove the second memory object from the cycle-unlikely buffer in response to determining the second memory object is part of the second garbage cycle.
[0033] In some aspects of the system for computer-implemented memory reclamation, the determining whether the cycle-unlikely buffer should be scanned comprising determining whether a current collection number C is a multiple of a cycle-unlikely frequency U.
[0034] In some aspects, there is provided at least one non-transitory machine-readable storage medium, including scanning a first memory object within a cycle-likely buffer; reclaiming a device memory location associated with the first memory object if the first memory object is part of a first garbage cycle; determining whether a cycle-unlikely buffer should be scanned; scanning a second memory object within the cycle-unlikely buffer; and reclaiming a device memory location associated with the second memory object if the second memory object is part of a second garbage cycle.
[0035] In some aspects, there is provided a non-transitory computer- readable storage media, wherein scanning the cycle -unlikely buffer occurs less frequently than scanning the cycle-likely buffer.
[0036] In some aspects, there is provided an at least one non-transitory machine-readable storage medium, the instructions further causing the processor circuitry to determine the first memory object is not part of the first garbage cycle; and store the first memory object within the cycle -unlikely buffer.
[0037] In some aspects, there is provided an at least one non-transitory machine-readable storage medium, the instructions further causing the processor circuitry to mark a first memory type of the first memory object as cycle- unlikely in response to a determination that the first memory object is not part of the first garbage cycle; and store the first memory object within the cycle- unlikely buffer.
[0038] In some aspects, there is provided an at least one non-transitory machine-readable storage medium, wherein the second garbage cycle includes a pair of mutual references between the second memory object and a third memory object.
[0039] In some aspects, the second garbage cycle includes the pair of mutual references without an external memory pointer being associated with either the second memory object or the third memory object.
[0040] In some aspects, the instructions further causing the at least one processor to decrement a reference count of the third memory object.
[0041] In some aspects, the instructions further causing the at least one processor to: determine the reference count is greater than zero; determine whether the third memory object is cycle-likely or cycle -unlikely and add the third memory object to the cycle-likely buffer or the cycle-unlikely buffer; and mark the third memory object to indicate the third memory object is stored in the cycle-likely buffer or the cycle -unlikely buffer.
[0042] In some aspects, marking the first memory object includes changing an object header bit flag or storing a hash table entry.
[0043] In some aspects, the instructions further causing the at least one processor to: determine the reference count is zero; and release the third memory object.
[0044] In some aspects, the instructions further causing the at least one processor to remove the first memory object from the cycle-likely buffer in response to determining the first memory object is part of the first garbage cycle. [0045] In some aspects, the instructions further causing the at least one processor to remove the second memory object from the cycle -unlikely buffer in response to determining the second memory object is part of the second garbage cycle.
[0046] In some aspects, the determining whether the cycle-unlikely buffer should be scanned comprising determining whether a current collection number C is a multiple of a cycle-unlikely frequency U.
[0047] Any one of the foregoing examples may be combined with any one or more of the other foregoing examples to create a new embodiment within the scope of the present disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
[0048] In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. The drawings illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document.
[0049] FIGs. 1A-1D are block diagrams illustrating memory heap snapshots, according to an example embodiment.
[0050] FIGs. 2A-2D are block diagrams illustrating a memory cycle, according to an example embodiment.
[0051] FIGs. 3A-3C are block diagrams illustrating a memory cycle scan, according to an example embodiment.
[0052] FIG. 4 is a block diagram illustrating a memory garbage cycle collection, according to an example embodiment.
[0053] FIG. 5 is a flowchart illustrating a memory garbage cycle collection method, according to an example embodiment.
[0054] Fig. 6 is a flowchart illustrating a memory garbage cycle collection method according to another embodiment.
[0055] FIG. 7 is a flowchart illustrating a memory buffer allocation method, according to an example embodiment.
[0056] FIG. 8 is a flowchart illustrating a method for computer- implemented memory reclamation, according to an example embodiment.
[0057] FIG. 9 is a block diagram illustrating a representative software architecture, which may be used in conjunction with various device hardware described herein, according to some example embodiments. [0058] FIG. 10 is a block diagram illustrating circuitry for a device that implements algorithms and performs methods, according to some example embodiments.
DETAILED DESCRIPTION
[0059] It should be understood at the outset that although an illustrative implementation of one or more embodiments is provided below, the disclosed systems or methods described in connection with the figures may be implemented using any number of techniques, whether currently known or not yet in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
[0060] In the following description, reference is made to the accompanying drawings that form a part hereof, and which are shown by way of illustration specific embodiments which may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be used, and that structural, logical, and electrical changes may be made without departing from the scope of the present invention. The following description of example embodiments is, therefore, not to be taken in a limited sense, and the scope of the present invention is defined by the appended claims.
[0061] The functions or algorithms described herein may be implemented in software in one embodiment. The software may consist of computer-executable instructions stored on computer-readable media or a computer-readable storage device such as one or more non-transitory memories or other types of hardware -based storage devices, either local or networked. Further, such functions correspond to modules, which may be software, hardware, firmware, or any combination thereof. Multiple functions may be performed in one or more modules as desired, and the embodiments described are merely examples. The software may be executed on a digital signal processor, ASIC, microprocessor, or another type of processor operating on a computer system, such as a personal computer, server, or another computer system, turning such computer system into a specifically programmed machine. [0062] FIGs. 1A-1D are block diagrams illustrating memory heap snapshots 100, according to an example embodiment. As shown in FIG. 1A, the first memory heap snapshot 110 includes a memory object X that is created on the memory heap and assigned to first pointer Pl. As used herein, a memory object describes a block or region of memory that is used to store information for later retrieval and use. When the first pointer Pl is assigned to the address associated with memory object X, this increases the reference count (RC) to 1. The RC in this example comprises a reference count associated with the memory object X. Each such memory object can have an associated RC. At the second memory heap snapshot 120 of FIG. IB, a second pointer P2 is also assigned to the address associated with memory object X, this increases the RC to 2.
[0063] At the third memory heap snapshot 120 of FIG. 1C, the first memory pointer Pl is reassigned to an address that is not associated with memory object X, which decreases the RC to 1. At the fourth memory heap snapshot 140 of FIG. ID, the second memory pointer P2 is also reassigned to an address that is not associated with memory object X, which decreases the RC to 0. When the RC for memory object X is reduced to zero, the memory object X represents a memory region that can be reclaimed (e.g., garbage memory that can be recycled).
[0064] When using the RC count for memory management, the memory management overhead is interspersed with program execution. Memory reclamation is evenly spread out through program execution, which may provide improved program performance by reducing or minimizing program execution pauses due to garbage memory collection. Additionally, garbage memory may be reclaimed as soon as that memory region is no longer referenced (e.g., RC = 0), which allows memory reclamation in an incremental fashion.
[0065] FIGs. 2A-2D are block diagrams illustrating formation of a memory cycle 200, according to an example embodiment. As shown in FIG. 2A, a first memory heap snapshot 210 includes a pointer P that points to a first memory object VS, and the first memory object VS has an associated RC = 1. At the second memory heap snapshot 220 of FIG. 2B, the first memory object VS points to a second memory object VT, and second memory object VT has an associated RC = 1. At the third memory heap snapshot 220 of FIG. 2C, the second memory object VT points back to the first memory object VS, increasing the first memory object VS to RC = 2. At the fourth memory heap snapshot 240 of FIG. 2D, the reference from pointer P to the first memory object VS is removed, reducing the first memory object VS to RC = 1.
[0066] At the stage shown in the fourth memory heap snapshot 240 of FIG. 2D, the first memory object VS and the second memory object VT point to each other, but neither is referenced by external pointer. At this stage, both memory objects have RC > 0, but form a self-referential garbage memory cycle. A memory management scheme may be improved by addressing such a garbage reference cycle to identify and reclaim memory objects that have RC > 0 but are not referenced by an external pointer. Reclaiming these memory regions may include marking each memory region (e.g., device memory location) as available for use, erasing that memory region, storing new data within that memory region, and other memory operations consistent with available memory regions. [0067] FIGs. 3A-3C are block diagrams illustrating a memory cycle scan 300, according to an example embodiment. FIG. 3 A shows an initial state 310 of a group of memory objects. In the initial state 310, memory object R 305 is not referenced by any pointer or other memory object, and is represented as “R_0” to indicate memory object R 305 has an associated RC = 0. Memory object A 315 is referenced by memory object R 305 and memory object B 325, so memory object A 315 has an associated RC = 2. Memory object A 315 and memory object B 325 reference each other, and form a memory reference cycle. Memory object C 335 is referenced by memory object B 325 and by memory object Y 340. Similarly, memory object D 345 is referenced by memory object C 335 and by memory object Z 350.
[0068] FIG. 3B shows a memory cycle candidate identification state 320. When the pointer from memory object R 305 to memory object A 315 is removed, then memory object A 315 is identified as a potential memory reference cycle candidate. However, before the memory cycle combination of memory object A 315 and memory object B 325 may be removed, the descendent memory objects (e.g., pointer-based downstream memory objects) are visited and marked based on whether descendent memory objects reference memory object A 315. In the example shown in FIG. 3B, the descendant memory objects B, C, and D are visited and marked as downstream memory objects.
[0069] FIG. 3C shows a memory scanning state 320, where each descendent memory object is scanned to determine whether it is referenced by another memory object. In the example shown in FIG. 3C, the scan identifies that memory object C 335 is referenced by memory object Y 340, and that memory object D 345 is referenced by memory object Z 350. This indicates that memory object C 335 and memory object D 345 should not be reclaimed, but that memory object A 315 and memory object B 325 form a garbage memory cycle and may be removed.
[0070] FIG. 4 is a block diagram illustrating a differential memory garbage cycle collection system 400, according to an example embodiment. This memory garbage cycle collection system 400 may be used to identify and store memory objects as cycle-likely or cycle-unlikely, and any stored memory objects that are identified as garbage memory cycle regions may be reclaimed. The memory garbage cycle collection system 400 provides improved memory management by separating memory cycle candidates into at least two buffers. The memory cycle candidates may include cycle-likely data type memory objects that are likely to be included as part of a garbage memory cycle, and may include cycle -unlikely data type memory objects that are unlikely to be included as part of a garbage memory cycle. Each of these memory cycle candidates may be held within a corresponding buffer within buffers 405. Buffers 405 may include two or more data buffers, where each data buffer is a region of a memory used for non-permanent data storage. In an example, buffers 405 include a cycle-likely buffer 410 (e.g., likely buffer) that holds cycle-likely data type memory objects, and include a cycle-unlikely buffer 415 (e.g., unlikely buffer) that holds cycle -unlikely data type memory objects.
[0071] A memory cycle garbage collector 420 may be used to collect cycle-garbage from the cycle-likely buffer 410 and from the cycle -unlikely buffer 415. In an embodiment, the collection of cycle-garbage from the cycle- unlikely buffer 415 may include using the memory cycle scan 300. These memory collections may be performed periodically (e.g., a lazy local-scan), such as in response to the expiration of a predetermined scan delay period. A different collection period (e.g., collection frequency) may be used for each of the cycle-likely buffer 410 and the cycle-unlikely buffer 415. Consequently, the cycle-likely buffer 410 is scanned more frequently than the cycle-unlikely buffer 415. In an example, memory objects in the cycle-likely buffer 410 are scanned every time the system scans for cycles (e.g., every collection cycle), but memory objects in the cycle-unlikely buffer 415 are scanned less frequently (e.g., every two or three collections, for example, depending on the multiple M).
[0072] Scanning the cycle -unlikely buffer 415 less frequently provides various advantages. This reduced scanning frequency for the cycle-unlikely buffer 415 reduces the average number of scanned candidates per collection, resulting in a shorter pause time during scanning. This modified scanning frequency also reduces the overall number of scanned candidates, resulting in a reduced computation overhead for garbage memory collection. Additionally, memory objects that are not part of garbage memory cycles have a greater possibility of being identified as reclaimable garbage memory and being removed from the buffers 405 before they are scanned. By removing (noncycle) memory objects from the buffers 405 before they are scanned, fewer memory objects are scanned, further reducing the total computation overhead for garbage memory collection. This provides a further improvement on the memory cycle scan 300 by reducing or avoiding the need to scan all descendants of a memory cycle candidate multiple times.
[0073] Based on the results of the dynamic classification by the classifier 425, each memory object may have its associated cycle-likeness information 430 stored in a memory. The cycle-likeness information may include the use of one or more data structures to indicate whether the memory object is cycle-likely or cycle-unlikely. If the computing system supports datatype objects (e.g., a data type represented by a special object), a binary bit may be stored in the object header or within the type object itself, and may be used as a flag to indicate cycle-like liness of the data type. A hash table may also be used to hold data types that are associated with each memory object. As a result, the cycle- likeliness information can be applied to objects of a same object type.
[0074] A runtime RC system 440 may be used to monitor pointers and increase or decrease the RC for each memory object. When the runtime RC system 440 decreases the RC for a memory object, that memory object may be added to cycle-likely buffer 410 or to the cycle -unlikely buffer 415, based on the associated cycle-likeness information 430 stored in memory.
[0075] It should be understood that the cycle-likely buffer 410 in some embodiments is scanned more often than the cycle-unlikely buffer 415. A memory object can be retained in the cycle-likely buffer 410 for one or more garbage memory collection iterations, including for an iteration or iterations after the object is initially added to the cycle-likely buffer 410.
[0076] For garbage collection, each object is given a reference count (RC). When a new pointer is added for a particular object, its RC is incremented. When an existing pointer is removed, the RC is decremented. When the RC for the particular object is decremented down to zero, the particular object becomes garbage, and the memory allocated to the particular object is reclaimed.
[0077] One problem with this conventional garbage collection is that it cannot handle a circular structure (or cycle), such as where object A points to object B, and object B points to object A. Even if no other objects point to object A and object B, their RCs >= 1, and their RCs cannot ever be decremented to zero. As a result, the memory for object A and object B cannot be reclaimed, and object A and object B are labeled a garbage cycle. However, objects A and B can be reclaimed at a next garbage collection cycle if objects A and B are determined to be part of a garbage cycle.
[0078] When a cycle has been created, the RC will not be able to be decremented down to zero. The only situation where a garbage cycle can be created (and can be determined) is when a RC decrease has been performed, but the RC does not (and cannot) become zero. It should be understood that a garbage cycle can comprise two objects, or more than two objects.
[0079] The RC of a memory object can be incremented or decremented upon a change to the memory object. Alternatively, the RC can be updated at regular or irregular intervals, such as periodically, per each processing loop, or according to other criteria. The updating of RC values does not necessarily coincide with garbage collection times. A particular garbage collection time operates on RC values existing at that time, and according to a scan of the cycle- likely buffer 410. If the garbage collection time coincides with the time for scanning both the cycle-likely buffer 410 and the cycle-unlikely buffer 415, then a memory object can be maintained in a current buffer or can be moved between buffers.
[0080] In some embodiments, the cycle-likeliness information applies to an object. In other embodiments, the cycle-likeliness information applies to a class or group of objects.
[0081] In some embodiments, when an object is to be put into either the cycle-likely buffer or the cycle-unlikely buffer, the object is put into the cycle- likely buffer by default. In other embodiments, the object is put into the cycle- unlikely buffer by default. In yet other embodiments, the object is put into the cycle-unlikely buffer if the object type indicator is not set, and is put into the cycle-likely buffer if the object type indicator is set.
[0082] In some embodiments, the cycle-likeliness information is set when a garbage cycle is detected. For example, the cycle-likeliness information is set during a time when the cycle-likely or cycle -unlikely buffer is scanned. [0083] The cycle-likeliness information is typically not cleared when the object is reclaimed. However, in some embodiments the cycle-likeliness information can be cleared, such as when: 1) a predefined number of garbage collection cycles have passed since the cycle-likeliness information was originally set, 2) a predefined number of garbage collection cycles have passed since the cycle-likeliness information was originally set and the indicator was not determined to still apply since the original setting of the cycle-likeliness information (i.e., the set cycle-likeliness information would have been set at a later time if it had not already been set), 3) a predetermined change has occurred in the corresponding application, or 4) the corresponding object (or object type) has not been created again before expiration of a timer (i.e., a non-use timer for the object or object type begins to run at a last reclamation and the cycle- likeliness information is cleared when the timer expires). It should be understood that other conditions can be used for determining whether the cycle- likeliness information should be cleared, and the clearing of the cycle-likeliness information is within the scope of the description and claims.
[0084] FIG. 5 is a flowchart illustrating a memory garbage cycle collection method 500, according to an example embodiment. The memory garbage cycle collection method 500 shows an example method that may be used with the memory garbage cycle collection system 400. The memory garbage cycle collection method 500 implements the different collection frequencies used by memory cycle garbage collector 420 for each of the cycle- likely buffer and the cycle-unlikely buffer. The memory garbage cycle collection method 500 may be repeated for each collection cycle.
[0085] At first step 510, a garbage collection operation is begun, with the garbage collection being directed to collection and reclamation of cyclic garbage.
[0086] In some embodiments, the garbage collection is begun depending on stored variables. A variable C may represent the current collection number, and variable U may represent the number of collection cycles between two successive scans of the cycle-unlikely buffer. It should be understood that the variables C and U are merely one way of setting the times for servicing the cycle-likely buffer and the cycle-unlikely buffer and controlling the frequency of the cycle-likely processing with respect to the cycle-unlikely processing. At second step 520, each memory object in the cycle-likely buffer is scanned for garbage memory cycles. At third step 530, the data type associated with each of the memory objects that is not in a garbage memory cycle is marked as cycle- unlikely. At fourth step 540, the data type associated with each of the memory objects that is in a garbage memory cycle is marked as cycle-likely.
[0087] At fifth step 550, it is determined if the garbage collection condition is met for scanning the cycle-unlikely buffer. As previously noted, the cycle-likely buffer is checked more frequently than the cycle-unlikely buffer. In some embodiments, the garbage collection condition comprises whether the current collection number C is a multiple of the cycle-unlikely frequency variable U. If C is a multiple of U, then in this embodiment each object in the cycle-unlikely buffer is scanned at sixth step 560. At seventh step 570, for each object in the cycle-unlikely buffer that is part of a garbage memory cycle, its associated data type is marked as cycle-likely. In an example, when variable U is set to three, then the cycle-unlikely buffer is scanned at sixth step 560 and may be marked at seventh step 570 at every third collection cycle.
[0088] Example pseudocode associated with memory garbage cycle collection method 500 is shown below:
Figure imgf000017_0001
Figure imgf000018_0001
[0089] In some embodiments the condition 550 in FIG. 5 for scanning the cycle -unlikely buffer is determined at runtime based on historic behavior of the program and/or the garbage collection.
[0090] In some embodiments the condition 550 in FIG. 5 for scanning the cycle-unlikely buffer is that the size of the buffer exceeds a certain size. The size can be pre-determined or changed based on runtime behavior.
[0091] In some embodiments the condition 550 in FIG.5 for scanning the cycle-unlikely buffer is that the amount of available memory is below a certain threshold. The threshold can be pre-determined or changed based on runtime behavior.
[0092] Fig. 6 is a flowchart illustrating a memory garbage cycle collection method 600 according to another embodiment.
[0093] At step 604, first memory object is scanned. The first memory object is reference by the cycle-likely buffer.
[0094] At step 606, it is determined whether the first memory object is within a garbage cycle. If the first memory object is within a garbage cycle, then the method proceeds to step 610. Otherwise, the method branches to step 615.
[0095] At step 610, the first memory object is reclaimed. Additionally, the first memory object is removed from the cycle-likely buffer. [0096] At step 615, it is determined whether the cycle -unlikely buffer should be checked. The cycle-unlikely buffer should be checked in one embodiment when the variable C is a multiple of U. However, other variables can alternatively control when the cycle-unlikely buffer should be checked. Here, the scan of the cycle-likely buffer may have just been conducted, and now the cycle -unlikely buffer is checked. This occurs when C is a multiple of U, and then both the cycle-likely and the cycle-unlikely buffer are scanned. If the cycle-unlikely buffer should be checked, then the method will proceed to step 617. Otherwise, the method will branch back to step 604 and the monitoring will continue.
[0097] At step 617, a second memory object will be scanned. The second memory object is within the cycle -unlikely buffer.
[0098] At step 620, it is determined whether the second memory object is within a garbage cycle. If the second memory object is within a garbage cycle, then the method proceeds to step 623. Otherwise, the method branches back to step 604 and the monitoring will continue.
[0099] At step 623, the second memory object is reclaimed. Additionally, the second memory object is removed from the cycle-unlikely buffer.
[00100] FIG. 7 is a flowchart illustrating a memory buffer allocation method 700, according to an example embodiment. The memory buffer allocation method 700 shows an example method that may be used by the runtime RC system 440 to add a new memory cycle candidate object to the cycle-likely buffer or the cycle-unlikely buffer. At first step 710, the memory object is analyzed to determine whether that memory object is already within a buffer. If that memory object is not within a buffer, at second step 720, the cycle-likeliness information forthat memory object is retrieved.
[00101] At third step 730, the cycle likeliness information forthat memory object is analyzed to determine whether the object is cycle-likely. If the memory object is cycle-likely, then the object is added to the cycle-likely buffer at step 740. If the memory object is cycle-unlikely, then the object is added to the cycle -unlikely buffer at step 745. Once the memory object has been added to a buffer, the memory object is marked (e.g., in the object header) as having been added to a buffer at step 750. [00102] Memory buffer allocation method 700 may be called in response to a determination that the RC of a memory object has been reduced but remains above zero. For example, whenever an RC decrease is performed on a memory object, if RC is not zero after the decrease, the object could be a candidate for a cycle-object and the object is added to the candidate buffer. The candidate buffer may be used by memory buffer allocation method 700 to allocate each memory object into its associated buffer. Example pseudocode for this RC decrease and memory buffer allocation method 700 is shown below:
Figure imgf000020_0001
[00103] FIG. 8 is a flowchart illustrating a method for computer- implemented memory reclamation 800, according to an example embodiment. At step 810, method 800 includes collecting, at a memory cycle garbage collector, a first memory object from a cycle-likely buffer, and a second memory object from a cycle-unlikely buffer. In an embodiment, collecting the second memory object from the cycle-unlikely buffer occurs less frequently than collecting the first memory object from the cycle-likely buffer. At step 820, method 800 includes marking the second memory object as cycle-likely in response to a determination that the second memory object is part of a garbage cycle. At step 830, method 800 includes determining the second memory object is part of a garbage cycle. At step 840, method 800 includes reclaiming a device memory location (e.g., computing device memory addresses) associated with the second memory object. Reclaiming the device memory location may include marking the device memory location as available for use, erasing the device memory location, storing new data within the device memory location, or other memory operations consistent with available device memory locations.
[00104] At step 850, method 800 may include determining the first memory object is not part of the garbage cycle, and storing the first memory object within the cycle-unlikely buffer. At step 860, method 800 may include marking a first memory type of the first memory object as cycle-unlikely in response to a determination that the first memory object is not part of a garbage cycle, and storing the first memory object within the cycle -unlikely buffer. In an embodiment, the garbage cycle includes a pair of mutual references between the second memory object and a third memory object. In an embodiment, the garbage cycle includes the pair of mutual references without a memory pointer associated with either the second memory object or the third memory object. [00105] At step 870, method 800 may include decrementing a reference count of a new memory object. At step 880, method 800 may include determining whether the new memory object is cycle-likely or cycle-unlikely, adding the new memory object to the cycle-likely buffer or the cycle-unlikely buffer, and marking the new memory object to indicate it is stored in a buffer. In an embodiment, marking the first memory object as cycle -likely or cycle - unlikely includes changing a memory object header bit flag (e.g., a cycle-likely bit flag or cycle-unlikely bit flag) or storing a hash table entry (e.g., storing a hash of the memory object with an associated cycle-likely flag or cycle-unlikely flag). At step 890, method 800 may include determining the reference count is zero and releasing the new memory object, thereby freeing the underlying memory region associated with the new memory object.
[00106] FIG. 9 is a block diagram 900 illustrating a representative software architecture, which may be used in conjunction with various device hardware described herein, according to some example embodiments. FIG. 9 is merely a non-limiting example of a software architecture 902 and it will be appreciated that many other architectures may be implemented to facilitate the functionality described herein. The software architecture 902 may be executing on hardware such as computing device 1000 of FIG. 10 that includes, among other things, processor 1005, memory 1010, storage 1015 and 1020, and I/O interfaces 1025 and 1030. A representative hardware layer 904 is illustrated and can represent, for example, the computing device 1000 of FIG. 10. The representative hardware layer 904 comprises one or more processing units 906 having associated executable instructions 908. Executable instructions 908 represent the executable instructions of the software architecture 902, including implementation of the methods, modules, and so forth of FIGs. 1-2. Hardware layer 904 also includes memory and/or storage modules 910, which also have executable instructions 908. Hardware layer 904 may also comprise other hardware 912, which represents any other hardware of the hardware layer 904, such as the other hardware illustrated as part of computing device 1000.
[00107] In the example architecture of FIG. 9, the software architecture 902 may be conceptualized as a stack of layers where each layer provides particular functionality. For example, the software architecture 902 may include layers such as an operating system 914, libraries 916, frameworks/middleware 918, applications 920, and presentation layer 944. Operationally, the applications 920 and/or other components within the layers may invoke application programming interface (API) calls 924 through the software stack and receive a response, returned values, and so forth illustrated as messages 926 in response to the API call 924. The layers illustrated in FIG. 9 are representative in nature and not all software architectures 902 have all layers. For example, some mobile or special purpose operating systems may not provide frameworks/middleware 918, while others may provide such a layer. Other software architectures may include additional or different layers.
[00108] The operating system 914 may manage hardware resources and provide common services. The operating system 914 may include, for example, a kernel 928, services 930, and drivers 932. The kernel 928 may act as an abstraction layer between the hardware and the other software layers. For example, kernel 928 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and so on. The services 930 may provide other common services for the other software layers. The drivers 932 may be responsible for controlling or interfacing with the underlying hardware. For instance, the drivers 932 may include display drivers, camera drivers, Bluetooth® drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, audio drivers, power management drivers, and so forth, depending on the hardware configuration.
[00109] The libraries 916 may provide a common infrastructure that may be utilized by the applications 920 and/or other components and/or layers. The libraries 916 typically provide functionality that allows other software modules to perform tasks more easily than to interface directly with the underlying operating system 914 functionality (e.g., kernel 928, services 930, and drivers 932). The libraries 916 may include system libraries 934 (e.g., C standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like. Also, the libraries 916 may include API libraries 936 such as media libraries (e.g., libraries to support presentation and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g., an OpenGU framework that may be used to render 2D and 3D in a graphic content on a display), database libraries (e.g., SQUite that may provide various relational database functions), web libraries (e.g., WebKit that may provide web browsing functionality), and the like. The libraries 916 may also include a wide variety of other libraries 938 to provide many other APIs to the applications 920 and other software components/modules.
[00110] The frameworks/middleware 918 (also sometimes referred to as middleware) may provide a higher-level common infrastructure that may be utilized by the applications 920 and/or other software components/modules. For example, the frameworks/middleware 918 may provide various graphical user interface (GUI) functions, high-level resource management, high-level location services, and so forth. The frameworks/middleware 918 may provide a broad spectrum of other APIs that may be utilized by the applications 920 and/or other software components/modules, some of which may be specific to a particular operating system 914 or platform.
[00111] The applications 920 include built-in applications 940, third-party applications 942, and container module 960. The container module 960 can include an application. Examples of representative built-in applications 940 may include but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and/or a game application. Third-party applications 942 may include any of the built-in applications 940 as well as a broad assortment of other applications. In a specific example, the third-party application 942 (e.g., an application developed using the Android™ or iOS™ software development kit (SDK) by an entity other than the vendor of the particular platform) may be mobile software running on a mobile operating system such as iOS™, Android™, Windows® Phone, or other mobile operating systems. In this example, the third-party application 942 may invoke the API calls 924 provided by the mobile operating system such as operating system 914 to facilitate the functionality described herein.
[00112] The applications 920 may utilize built-in operating system functions (e.g., kernel 928, services 930, and drivers 932), libraries (e.g., system libraries 934, API libraries 936, and other libraries 938), and frameworks/middleware 918 to create user interfaces to interact with users of the system. Alternatively, or additionally, in some systems, interactions with a user may occur through a presentation layer, such as presentation layer 944. In these systems, the application/module “logic” can be separated from the aspects of the application/module that interact with a user.
[00113] Some software architectures utilize virtual machines. In the example of FIG. 9, this is illustrated by virtual machine 948. A virtual machine creates a software environment where applications/modules can execute as if they were executing on a hardware machine (such as the computing device 1000 of FIG. 10, for example). A virtual machine 948 is hosted by a host operating system (operating system 914 in FIG. 9) and typically, although not always, has a virtual machine monitor 946, which manages the operation of the virtual machine 948 as well as the interface with the host operating system (i.e., operating system 914). A software architecture 902 executes within the virtual machine 948 such as an operating system 950, libraries 952, frameworks/middleware 954, applications 956, and/or presentation layer 958. These layers of software architecture executing within the virtual machine 948 can be the same as corresponding layers previously described or may be different.
[00114] FIG. 10 is a block diagram 1000 illustrating circuitry for a device that implements algorithms and performs methods, according to some example embodiments. All components need not be used in various embodiments. For example, clients, servers, and cloud-based network devices may each use a different set of components, or in the case of servers, larger storage devices. [00115] One example computing device in the form of a computer 1000 (also referred to as computing device 1000, computer system 1000, or computer 1000) may include a processor 1005, memory 1010, a removable storage 1015, a non-removable storage 1020, an input interface 1025, an output interface 1030, and a communication interface 1035, all connected by a bus 1040. Although the example computing device is illustrated and described as the computer 1000, the computing device may be in different forms in different embodiments.
[00116] The memory 1010 may include volatile memory 1045 and nonvolatile memory 1050 and may store a program 1055. The computer 1000 may include or have access to a computing environment that includes a variety of computer-readable media, such as the volatile memory 1045, the non-volatile memory 1050, the removable storage 1015, and the non-removable storage 1020. The memory 1010 includes random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD ROM), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium capable of storing computer-readable instructions.
[00117] Computer-readable instructions stored on a computer-readable medium (e.g., the program 1055 stored in memory 1010) are executable by the processor 1005 of the computer 1000. Program 1055 may utilize one or more modules discussed herein. A hard drive, CD-ROM, and RAM are some examples of articles including a non-transitory computer-readable medium such as a storage device. The terms “computer-readable medium” and “storage device” do not include carrier waves to the extent that carrier waves are deemed too transitory. “Computer-readable non-transitory media” includes all types of computer-readable media, including magnetic storage media, optical storage media, flash media, and solid-state storage media. It should be understood that software can be installed on and sold with a computer. Alternatively, the software can be obtained and loaded into the computer, including obtaining the software through a physical medium or distribution system, including, for example, from a server owned by the software creator or from a server not owned but used by the software creator. The software can be stored on a server for distribution over the Internet, for example. As used herein, the terms “computer-readable medium” and “machine-readable medium” are interchangeable.
[00118] In an example embodiment, the computer 1000 includes means for retrieving application data from a computing device of the plurality of computing devices, the application data including an application identification (ID), and a first application version number of an application executing on the computing device. The computer 1000 further includes means for updating a first database table using object type information associated with the application ID and the first application version number, the object type information identifying a database table schema of a data object used by the application, and a plurality of data fields of the data object. The computer 1000 further includes means for synchronizing the data object using synchronization data for the plurality of data fields received from the second computing device to generate a synchronized data object. The computer 1000 further includes means for receiving a second application version number from a second computing device, the second application version number associated with the application executing on the second computing device, in response to a notification of the synchronized data object communicated to the second computing device. The computer 1000 further includes means for selecting one or more of the plurality of data fields of the synchronized data object, based on the second application version number, and means for communicating data stored by the one or more of the plurality of data fields to the third computing device for synchronization. In some embodiments, the computer 1000 may include other or additional modules for performing any one or combination of steps described in the embodiments. Further, any of the additional or alternative embodiments or aspects of the method, as shown in any of the figures or recited in any of the claims, are also contemplated to include similar modules.
[00119] Any one or more of the modules described herein may be implemented using hardware (e.g., a processor of a machine, an applicationspecific integrated circuit (ASIC), field-programmable gate array (FPGA), or any suitable combination thereof). Moreover, any two or more of these modules may be combined into a single module, and the functions described herein for a single module may be subdivided among multiple modules. Furthermore, according to various example embodiments, modules described herein as being implemented within a single machine, database, or device may be distributed across multiple machines, databases, or devices.
[00120] Although a few embodiments have been described in detail above, other modifications are possible. For example, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. Other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Other embodiments may be within the scope of the following claims.
[00121] It should be further understood that software including one or more computer-executable instructions that facilitate processing and operations as described above concerning any one or all of the steps of the disclosure can be installed in and sold with one or more computing devices consistent with the disclosure. Alternatively, the software can be obtained and loaded into one or more computing devices, including obtaining software through a physical medium or distribution system, including, for example, from a server owned by the software creator or from a server not owned but used by the software creator. The software can be stored on a server for distribution over the Internet, for example.
[00122] Also, it will be understood by one skilled in the art that this disclosure is not limited in its application to the details of construction and the arrangement of components outlined in the description or illustrated in the drawings. The embodiments herein are capable of other embodiments and capable of being practiced or carried out in various ways. Also, it will be understood that the phraseology and terminology used herein are for description and should not be regarded as limiting. The use of “including,” “comprising,” or “having” and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless limited otherwise, the terms “connected,” “coupled,” and “mounted,” and variations thereof herein are used broadly and encompass direct and indirect connections, couplings, and mountings. Also, the terms “connected” and “coupled” and variations thereof are not restricted to physical or mechanical connections or couplings. Further, terms such as up, down, bottom, and top are relative and are employed to aid illustration, but are not limiting.
[00123] The components of the illustrative devices, systems, and methods employed per the illustrated embodiments can be implemented, at least in part, in digital electronic circuitry, analog electronic circuitry, computer hardware, firmware, software, or combinations of them. These components can be implemented, for example, as a computer program product such as a computer program, program code, or computer instructions tangibly embodied in an information carrier, or a machine -readable storage device, for execution by, or to control the operation of, data processing apparatus such as a programmable processor, a computer, or multiple computers.
[00124] A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or another unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or multiple computers at one site or distributed across multiple sites and interconnected by a communication network. Also, functional programs, codes, and code segments for accomplishing the techniques described herein can be easily construed as within the scope of the claims by programmers skilled in the art to which the techniques described herein pertain. Method steps associated with the illustrative embodiments can be performed by one or more programmable processors executing a computer program, code, or instructions to perform functions (e.g., by operating on input data and/or generating an output). Method steps can also be performed by, and apparatus for performing the methods can be implemented as, special purpose logic circuitry, e.g., an FPGA (field-programmable gate array) or an ASIC (application-specific integrated circuit), for example. [00125] The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP), an ASIC, an FPGA, or another programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g. , a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
[00126] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random-access memory, or both. The required elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile or non-transitory memory, including by way of example, semiconductor memory devices, e.g., electrically programmable read-only memory or ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory devices, and data storage disks (e.g., magnetic disks, internal hard disks, removable disks, magneto-optical disks, CD-ROM disks or DVD-ROM disks). The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
[00127] Those of skill in the art understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
[00128] As used herein, “machine-readable medium” (or “computer- readable medium”) means a device able to store instructions and data temporarily or permanently and may include, but is not limited to, randomaccess memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage (e.g., Erasable Programmable Read-Only Memory (EEPROM)), and/or any suitable combination thereof. The term “machine -readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store processor instructions. The term “machine-readable medium” shall also be taken to include any medium (or a combination of multiple media) that is capable of storing instructions for execution by one or more processors 905, such that the instructions, when executed by one or more processors 905, cause the one or more processors 905 to perform any one or more of the methodologies described herein. Accordingly, a “machine-readable medium” refers to a single storage apparatus or device, as well as “cloud-based” storage systems or storage networks that include multiple storage apparatus or devices. The term “machine- readable medium” as used herein excludes signals per se.
[00129] Also, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the scope disclosed herein.
[00130] Although the present disclosure has been described regarding specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the scope of the disclosure. For example, other components may be added to, or removed from, the described systems. The specification and drawings are, accordingly, to be regarded simply as an illustration of the disclosure as defined by the appended claims, and are contemplated to cover any modifications, variations, combinations, or equivalents that fall within the scope of the present disclosure. Other aspects may be within the scope of the following claims.

Claims

CLAIMS What is claimed is:
1. A method for computer-implemented memory reclamation, the method comprising: scanning a first memory object within a cycle -likely buffer; reclaiming a device memory location associated with the first memory object if the first memory object is part of a first garbage cycle; determining whether a cycle-unlikely buffer should be scanned; scanning a second memory object within the cycle-unlikely buffer; and reclaiming a device memory location associated with the second memory object if the second memory object is part of a second garbage cycle.
2. The method of claim 1, wherein scanning the cycle-unlikely buffer occurs less frequently than scanning the cycle-likely buffer.
3. The method of any of claims 1-2, further including: determining the first memory object is not part of the first garbage cycle; and storing the first memory object within the cycle-unlikely buffer.
4. The method of any of claims 1-3, further including: marking a first memory type of the first memory object as cycle-unlikely in response to a determination that the first memory object is not part of the first garbage cycle; and storing the first memory object within the cycle-unlikely buffer.
5. The method of any of claims 1-2, further including: determining the first memory object is part of the first garbage cycle.
6. The method of any of claims 1, 2, and 5, further including: marking a first memory type of the first memory object as cycle-likely in response to a determination that the first memory object is part of the first garbage cycle.
7. The method of any of claims 4 and 6, wherein the second garbage cycle includes a pair of mutual references between the second memory object and a third memory object.
8. The method of claim 7, wherein the second garbage cycle includes the pair of mutual references without an external memory pointer being associated with either the second memory object or the third memory object.
9. The method of any of claims 7-8, further including decrementing a reference count of the third memory object.
10. The method of claim 9, further including: determining the reference count is greater than zero; determining whether the third memory object is cycle-likely or cycle- unlikely and adding the third memory object to the cycle-likely buffer or the cycle-unlikely buffer; and marking the third memory object to indicate the third memory object is stored in the cycle-likely buffer or the cycle-unlikely buffer.
11. The method of claim 10, wherein marking the first memory object includes changing an object header bit flag or storing a hash table entry.
12. The method of any of claims 9-10, further including: determining the reference count is zero; and releasing the third memory object.
13. The method of any of claims 1-12, the method further comprising removing the first memory object from the cycle-likely buffer in response to determining the first memory object is part of the first garbage cycle.
14. The method of any of claims 1-12, the method further comprising removing the second memory object from the cycle -unlikely buffer in response to determining the second memory object is part of the second garbage cycle.
15. The method of any of claims 1-14, the determining whether the cycle- unlikely buffer should be scanned comprising: determining whether a current collection number C is a multiple of a cycle-unlikely frequency U.
16. A system for computer-implemented memory reclamation, the system comprising: a memory storing instructions; a cycle-likely buffer; a cycle-unlikely buffer; and at least one processor in communication with the memory, the cycle- likely buffer, and the cycle-unlikely buffer, the at least one processor configured, upon execution of the instructions, to perform the following steps: scan a first memory object within the cycle-likely buffer; reclaim a device memory location associated with the first memory object if the first memory object is part of a first garbage cycle; determine whether a cycle-unlikely buffer should be scanned; scan a second memory object within the cycle-unlikely buffer; and reclaim a device memory location associated with the second memory object if the second memory object is part of a second garbage cycle.
17. The system of claim 16, wherein scanning the cycle -unlikely buffer occurs less frequently than scanning the cycle-likely buffer.
18. The system of any of claims 16-17, further comprising the processing circuitry executing the instructions to: determine the first memory object is not part of the first garbage cycle; and store the first memory object within the cycle-unlikely buffer.
19. The system of any of claims 16-18, further comprising the processing circuitry executing the instructions to: mark a first memory type of the first memory object as cycle-unlikely in response to a determination that the first memory object is not part of the first garbage cycle; and store the first memory object within the cycle-unlikely buffer.
20. The system of claim 19, wherein the second garbage cycle includes a pair of mutual references between the second memory object and a third memory object.
21. The system of claim 20, wherein the second garbage cycle includes the pair of mutual references without an external memory pointer being associated with either the second memory object or the third memory object.
22. The system of any of claims 20-21, further comprising the processing circuitry executing the instructions to decrement a reference count of the third memory object.
23. The system of claim 22, further comprising the processing circuitry executing the instructions to: determine the reference count is greater than zero; determine whether the third memory object is cycle-likely or cycle- unlikely and add the third memory object to the cycle-likely buffer or the cycle- unlikely buffer; and mark the third memory object to indicate the third memory object is stored in the cycle-likely buffer or the cycle-unlikely buffer.
24. The system of claim 23, wherein marking the first memory object includes changing an object header bit flag or storing a hash table entry.
25. The system of claim 24, further comprising the processing circuitry executing the instructions to: determine the reference count is zero; and release the third memory object.
26. The system of any of claims 16-25, further comprising the processing circuitry executing the instructions to remove the first memory object from the cycle-likely buffer in response to determining the first memory object is part of the first garbage cycle.
27. The system of any of claims 16-25, further comprising the processing circuitry executing the instructions to remove the second memory object from the cycle -unlikely buffer in response to determining the second memory object is part of the second garbage cycle.
28. The system of any of claims 16-27, the determining whether the cycle- unlikely buffer should be scanned comprising: determining whether a current collection number C is a multiple of a cycle-unlikely frequency U.
29. A non-transitory computer-readable media storing computer instructions that configure at least one processor, upon execution of the instructions, to perform the following steps, comprising: scanning a first memory object within a cycle -likely buffer; reclaiming a device memory location associated with the first memory object if the first memory object is part of a first garbage cycle; determining whether a cycle-unlikely buffer should be scanned; scanning a second memory object within the cycle-unlikely buffer; and reclaiming a device memory location associated with the second memory object if the second memory object is part of a second garbage cycle.
30. The computer-readable media of claim 29, wherein scanning the cycle- unlikely buffer occurs less frequently than scanning the cycle-likely buffer.
31. The computer-readable media of any of claims 29-30, the instructions further causing the at least one processor to: determine the first memory object is not part of the first garbage cycle; and store the first memory object within the cycle-unlikely buffer.
32. The computer-readable media of any of claims 29-31, the instructions further causing the processor circuitry to: mark a first memory type of the first memory object as cycle-unlikely in response to a determination that the first memory object is not part of the first garbage cycle; and store the first memory object within the cycle-unlikely buffer.
33. The computer-readable media of claim 32, wherein the second garbage cycle includes a pair of mutual references between the second memory object and a third memory object.
34. The computer-readable media of claim 33, wherein the second garbage cycle includes the pair of mutual references without an external memory pointer being associated with either the second memory object or the third memory object.
35. The computer-readable media of any of claims 33-34, the instructions further causing the at least one processor to decrement a reference count of the third memory object.
36. The computer-readable media of claim 35, the instructions further causing the at least one processor to: determine the reference count is greater than zero; determine whether the third memory object is cycle-likely or cycle- unlikely and add the third memory object to the cycle-likely buffer or the cycle- unlikely buffer; and mark the third memory object to indicate the third memory object is stored in the cycle-likely buffer or the cycle-unlikely buffer.
37. The computer-readable media of claim 36, wherein marking the first memory object includes changing an object header bit flag or storing a hash table entry.
38. The computer-readable media of any of claims 29-37, the instructions further causing the at least one processor to: determine the reference count is zero; and release the third memory object.
39. The computer-readable media of any of claims 29-38, the instructions further causing the at least one processor to remove the first memory object from the cycle-likely buffer in response to determining the first memory object is part of the first garbage cycle.
40. The computer-readable media of any of claims 29-38, the instructions further causing the at least one processor to remove the second memory object from the cycle-unlikely buffer in response to determining the second memory object is part of the second garbage cycle.
41. The computer-readable media of any of claims 29-40, the determining whether the cycle-unlikely buffer should be scanned comprising: determining whether a current collection number C is a multiple of a cycle-unlikely frequency U.
PCT/US2022/079941 2022-11-16 2022-11-16 Differential collection of cyclic memory garbage WO2024049487A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2022/079941 WO2024049487A1 (en) 2022-11-16 2022-11-16 Differential collection of cyclic memory garbage

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2022/079941 WO2024049487A1 (en) 2022-11-16 2022-11-16 Differential collection of cyclic memory garbage

Publications (1)

Publication Number Publication Date
WO2024049487A1 true WO2024049487A1 (en) 2024-03-07

Family

ID=84488843

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/079941 WO2024049487A1 (en) 2022-11-16 2022-11-16 Differential collection of cyclic memory garbage

Country Status (1)

Country Link
WO (1) WO2024049487A1 (en)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080235309A1 (en) * 2000-12-11 2008-09-25 International Business Machines Corporation Concurrent Collection of Cyclic Garbage in Reference Counting Systems

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080235309A1 (en) * 2000-12-11 2008-09-25 International Business Machines Corporation Concurrent Collection of Cyclic Garbage in Reference Counting Systems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JONATHAN E COOK ET AL: "Partition selection policies in object database garbage collection", SIGMOD RECORD, ACM, NEW YORK, NY, US, vol. 23, no. 2, 24 May 1994 (1994-05-24), pages 371 - 382, XP058311181, ISSN: 0163-5808, DOI: 10.1145/191843.191913 *

Similar Documents

Publication Publication Date Title
TWI771332B (en) Resource recovery method and device
US6874074B1 (en) System and method for memory reclamation
US9298377B2 (en) Techniques for reducing read I/O latency in virtual machines
US9239841B2 (en) Hash-based snapshots
US6493730B1 (en) Efficient object faulting with generational garbage collection
CN110325969B (en) Multi-stage garbage collector
US9740716B2 (en) System and method for dynamically selecting a garbage collection algorithm based on the contents of heap regions
JP6163551B2 (en) System and method for deleting objects in persistent memory using a bitmap window
JP2013109756A (en) Method for tracking memory usages of data processing system
EP2115600A1 (en) Database management methodology
CN108459913B (en) Data parallel processing method and device and server
US11347698B2 (en) Garbage collection for hash-based data structures
US7831640B2 (en) Using an overflow list to process mark overflow
US11221947B2 (en) Concurrent garbage collection with minimal graph traversal
US20180103131A1 (en) Apparatus and Methods for Optimizing Dirty Memory Pages in Embedded Devices
US20180181487A1 (en) Generational garbage collector for trees under multi-version concurrency control
WO2024049487A1 (en) Differential collection of cyclic memory garbage
WO2021022274A1 (en) Deduplication based on consolidation of data fingerprints
EP3405870A1 (en) Versioned records management using restart era
CN109144708B (en) Electronic computing device and method for adjusting trigger mechanism of memory recovery function
US20210303462A1 (en) Deep object graph traversal
CN113342270A (en) Volume unloading method and device and electronic equipment
US9021496B2 (en) Method and program for recording object allocation site
JP6173031B2 (en) Method, program and system for managing objects in a computer
JP2014170430A (en) Memory management method, method and program for data element recovery, information processing apparatus, and method and program for controlling the information processing apparatus

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: 22822816

Country of ref document: EP

Kind code of ref document: A1