Patent Application
20120066270
1. Technical Field
This disclosure relates to automated memory management, including the reclamation of memory used by objects which are no longer reachable outside of the data structure in which they are members.
2. Description of Related Art
Complex, graph-like, in-memory, data structures which contain a large number of objects (e.g., in excess of 1000) may be suited to representing various domains. However, navigating and searching through them to respond to queries for specific objects may require an index for efficiency. The index may avoid the necessity to traverse long paths or to perform linear scans which might result in unacceptable query response times.
One indexing technique is to assign a unique, immutable key to each object and to maintain a separate index table which maps such keys to the individual objects. Objects in the table may be looked up using constant O(1) time using hashing techniques.
Using index tables, however, does not come without a cost. Modern platforms (e.g., JVM, .NET, and Flash) provide automated memory management using what is known as a “garbage collector.” The garbage collector is configured to reclaim memory which is occupied by objects which are no longer in use by an application program.
To determine whether an object is no longer in use, garbage collectors typically determine whether the object is “reachable” from outside of the data structure in which the object resides. This typically means that the object is referenced from outside of the data structure or by an object within the data structure which itself is reachable from outside of the data structure.
Unfortunately, index tables are themselves viewed by the garbage collector as objects which are reachable from outside of the data structure. Thus, even when an indexed object becomes unreachable, a garbage collector may regard the object as still being reachable, since it is still reachable through the index table which references it.
As a consequence, index tables may frustrate the automatic memory management which is provided by garbage collectors. Application programmers, therefore, have been compelled to write ad-hoc memory management routines within their application programs to manually reclaim memory occupied by indexed objects which, but for the index, have become unreachable. This can increase the size, cost, and complexity of application programs.
Non-transitory, tangible, computer-readable memory may be managed by a garbage collector. The memory may contain a data structure and an index. The data structure may include a plurality of objects. The index may index a plurality of the objects in the data structure. For each object which it indexes, the index may contain a key field and a reference to the object. The key field may be indicative of an attribute of the object. The reference to the object may be associated with the key field. The reference may have a format which does not prevent the garbage collector from reclaiming memory occupied by any unreachable object in the data structure, even though the object is still referenced by the index.
All of the references to each object in the index may be weak references.
The data structure may include a plurality of object groups.
The data structure may be an arbitrary data structure, arbitrarily complex, and/or a cyclical data structure.
The objects may include nodes and edges of a graph.
The index may be implemented as a hash map.
Non-transitory, tangible, computer-readable storage media may contain computer-readable instructions which, when executed by a computer system, cause the computer system to generate and write the data structure and the index into the memory.
The garbage collector may be configured to create a reference reclamation queue containing references to objects whose memory has been reclaimed by the garbage collector.
The instructions, when executed by the computer system, may cause the computer system to read the references in the reference reclamation queue.
The instructions, when executed by the computer system, may cause the computer system to remove entries in the index to objects whose memory has been reclaimed by the garbage collector, as indicated by the references in the reference reclamation queue.
The instructions may be part of an application program which is separate from the garbage collector and which does not contain any instructions which reclaim memory occupied by any of the objects in the data structure which are no longer reachable from outside of the data structure.
These, as well as other components, steps, features, objects, benefits, and advantages, will now become clear from a review of the following detailed description of illustrative embodiments, the accompanying drawings, and the claims.
The drawings illustrate illustrative embodiments. They do not illustrate all embodiments. Other embodiments may be used in addition or instead. Details which may be apparent or unnecessary may be omitted to save space or for more effective illustration. Some embodiments may be practiced with additional components or steps and/or without all of the components or steps which are illustrated. When the same numeral appears in different drawings, it refers to the same or like components or steps.
Illustrative embodiments are now described. Other embodiments may be used in addition or instead. Details which may be apparent or unnecessary may be omitted to save space or for a more effective presentation. Some embodiments may be practiced with additional components or steps and/or without all of the components or steps which are described.
As illustrated in
The computer-readable memory 107 may be of any type. For example, the computer-readable memory 107 may consist of or include one or more RAMS, ROMS, PROMS, and/or flash memories.
The application program 103 may be a software program of any type. For example, the application program 103 may be a database management program configured to manage data. As part of this management process, the application program 103 may be configured to write data objects in the computer-readable memory 107, as reflected by a Write Objects in Memory step 201 in
The application program 103 may be configured to generate the index 111 of some or all of the objects and to write the index 111 into the computer-readable memory 107, as reflected by a Write Index in Memory Using Weak References step 203 in
The garbage collector 105 may be a software program which is configured to reclaim portions of the computer-readable memory 107 which are occupied by objects within the data structure 109 which are no longer reachable from outside of the data structure 109 during a memory reclamation process.
The garbage collector 105 may be configured to employ a pointer tracer which follows references to objects as part of the process of determining whether the objects are no longer reachable from outside of the data structure 109. The garbage collector may be configured to distinguish between one type of reference called a “strong reference” and another type of reference called a “weak reference.” The pointer tracer may be configured to ignore weak references when determining whether an object is reachable from outside of the data structure 109, i.e., to only consider strong references during this task.
Conventional references between objects in memory are also known as “strong references” in connection with garbage collectors which supports different types of references. For example, a strong reference might refer to an Address object from an Account object, or from an abstract Node inside a Graph to another node linked to it. A weak reference might refer to the Account object from an index which indexes accounts by their account number. Strong references usually endure unless explicitly cleared by the Application code; and they may also make their referents reachable from the object holding the reference and therefore not reclaimable by the garbage collector.
Weak references may be implemented differently on different platforms. For example, on the JVM platform, they may be objects of type java.lang.ref.WeakRef whose field named “referent” refers to the object held through the weak reference. Weak references may not be followed by the garbage collector when determining reachability. If an object is reachable solely by following a weak reference, then it becomes subject to reclamation by the garbage collector and the corresponding weak reference may then be cleared (or set to null) in the objects containing it.
The application program 103 may not include any instructions which reclaim memory occupied by any of the objects in the data structure 109 which are no longer reachable from outside of the data structure 109.
As illustrated in
There may be a strong reference from each root to a respective object, as represented by the arrows pointing from the roots 301 to the objects 124, 321, and 65. Similarly, there may be strong references from certain objects, such as the objects 124 and 65, to other objects, such as the objects 4312 and 45, respectively. Based on the configuration illustrated in
The index 111 may include a key field 401 which may be indicative of an attribute of each object. The index 111 may include a weak reference 403 to each object. Each weak reference 403 may be associated with the key field 401 for the object. Each weak reference 403 may have a configuration which is not followed by the pointer tracer of the garbage collector 105 when the garbage collector seeks to determine which of the objects in the data structure 109 are no longer reachable from outside of the data structure 109 during a memory reclamation process. This may thus ensure that the index 111 does not prevent the memory occupied by any object in the data structure 109 which is no longer reachable from outside of the data structure 109 from being reclaimed by the garbage collector 105 during the memory reclamation process, even though the object is still referenced by the index 111.
The index 111 may be in any form. For example, the index may be a table and implemented as a hash map. The index 111 may index a plurality of the objects in the data structure 109, but not necessarily all of them.
The application program 103 may be configured to modify the data structure 109 so as to render one of its objects unreachable, as reflected by a Modify Data Structure Rendering Object(s) Unreachable step 205. This may occur, for example, when the application program 103 removes a strong root reference to an object and/or removes a strong reference in an object to another object.
The garbage collector 105 may be run next. This may be triggered, for example, by an instruction in the application program 103, by an instruction from an underlying operating system, by a periodic memory management timer, and/or by background operation of the run-time platform.
The garbage collector may reclaim the computer-readable memory 107 which had been occupied by what are not unreachable objects, as reflected by a Reclaim Memory Used By Unreachable Object(s) step 207. During this memory reclamation process, the garbage collector 105 may recognize that objects 21, 327, and 45 are no longer reachable from outside of the data structure 109. As a consequence, the garbage collector 105 may reclaim the memory which is occupied by these objects. This may take place, notwithstanding the fact that one or more of these objects, such as the objects 21 and 327 in the example illustrated in
During the memory reclamation process, the garbage collector 105 may be configured to store references to objects whose memory has been reclaimed in a reference reclamation queue.
The application program 103 may be configured to read the references that are in the reference reclamation queue 701, as reflected by a Read Reference Reclamation Queue step 209. The application program 103 may be configured to do so after directing that a change be made to one or more of the objects in the data structure 109, and after being informed that the garbage collector 105 has completed a memory reclamation cycle.
The application program 103 may be configured to remove entries in the index 111 to objects whose memory has been reclaimed by the garbage collector 105 during a memory reclamation process, as reflected by a Remove Entries in Index To Unreachable Object(s) step 211. These may be the objects identified by the references which the application program 103 read from the reference reclamation queue 701.
The computer programs which have been discussed herein, such as the application program 103, may be stored on non-transitory, tangible, computer-readable storage media, such as one or more CD's, DVD's, flash memories, and/or hard disk drives.
The components, steps, features, objects, benefits and advantages which have been discussed are merely illustrative. None of them, nor the discussions relating to them, are intended to limit the scope of protection in any way. Numerous other embodiments are also contemplated. These include embodiments which have fewer, additional, and/or different components, steps, features, objects, benefits and advantages. These also include embodiments in which the components and/or steps are arranged and/or ordered differently.
For example, the technology which has been described may be used for indexing a subset of a social network, a content management system for rich media publishing, and/or a universe of financial instruments, including their attributes, and relationships.
Unless otherwise stated, all measurements, values, ratings, positions, magnitudes, sizes, and other specifications which are set forth in this specification, including in the claims which follow, are approximate, not exact. They are intended to have a reasonable range which is consistent with the functions to which they relate and with what is customary in the art to which they pertain.
All articles, patents, patent applications, and other publications which have been cited in this disclosure are incorporated herein by reference.
The phrase “means for” when used in a claim is intended to and should be interpreted to embrace the corresponding structures and materials which have been described and their equivalents. Similarly, the phrase “step for” when used in a claim is intended to and should be interpreted to embrace the corresponding acts which have been described and their equivalents. The absence of these phrases in a claim mean that the claim is not intended to and should not be interpreted to be limited to any of the corresponding structures, materials, or acts or to their equivalents.
None of the claims are intended to embrace non-statutory subject matter, such as an abstract idea, law of nature or natural phenomena; obvious subject matter; nor subject matter lacking novelty, nor should they be interpreted in such a way. Any unintended embracement of such subject matter is hereby disclaimed.
Except as otherwise stated immediately above, nothing which has been stated or illustrated is intended or should be interpreted to cause a dedication of any component, step, feature, object, benefit, advantage, or equivalent to the public, regardless of whether it is recited in the claims.
The scope of protection is limited solely by the claims which now follow. That scope is intended and should be interpreted to be as broad as is consistent with the ordinary meaning of the language which is used in the claims when interpreted in light of this specification and the prosecution history which follows and to encompass all structural and functional equivalents.
