US6052699A - Garbage collection without fine-grain synchronization - Google Patents
Garbage collection without fine-grain synchronization Download PDFInfo
- Publication number
- US6052699A US6052699A US08/987,030 US98703097A US6052699A US 6052699 A US6052699 A US 6052699A US 98703097 A US98703097 A US 98703097A US 6052699 A US6052699 A US 6052699A
- Authority
- US
- United States
- Prior art keywords
- designation
- objects
- color
- garbage collection
- mutator
- Prior art date
- Legal status (The legal status 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 status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
- G06F12/0269—Incremental or concurrent garbage collection, e.g. in real-time systems
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99956—File allocation
- Y10S707/99957—Garbage collection
Definitions
- the present invention relates to memory management in computer systems, and more particularly, to garbage collection in such computer systems.
- ⁇ are executed by a microprocessor which necessarily uses memory locations for storing data and instructions.
- the contents of memory are changing over time such that, at different times, a memory location is said to be allocated, i.e., used, or unallocated, i.e., unused.
- allocated memory locations are those locations that contain data or instructions that are referenced by other allocation memory locations during normal program execution.
- an "object” is data that share a particular attribute and occupy a contiguous region of memory. If all objects in a given computer system are permanent, there is no real concern with regard to memory management. That is, the memory space assigned to each object at the start of program execution never changes. However, in most conventional object oriented systems, objects have varying lifetimes that cannot be predicted in advance such that memory locations will transition between allocated and unallocated states. In order to promote the efficient use of memory, unallocated memory locations must be "reclaimed” so that they may be later allocated as required.
- Garbage is a well-known term in the computer science arts which refers to memory storage locations which contain data that is no longer being used in, e.g., the execution of an application program. Garbage collection is another well-known term of art used in describing automatic techniques for identifying garbage and reclaiming those memory locations for future allocation. By automatically identifying accessible, and therefore potentially in-use data, e.g., objects, garbage collection routines shoulder the error-prone task of memory allocation and deallocation for the computer programmer. In freeing computer programmers from such low-level detail, garbage collection at a minimum can improve the quality of program code, increase programmer productivity, and reduce program development costs.
- garbage collection techniques such as “stop & copy”, “mark & sweep” and “reference counting” are described by, for example, Paul R. Wilson, “Uniprocessor Garbage Collection Techniques", In International Workshop on Memory Management, Springer-Verlag, 1992, and Richard Jones et al., Garbage Collection Algorithms for Automatic Dynamic Memory Management, John Wiley & Sons, 1996.
- the costs associated with such traditional garbage collection techniques manifest themselves, for example, as combinations of increased memory usage, run-time overheads on data accesses, and disruptive latencies in a program's execution.
- stop & copy garbage collectors require a substantial amount of additional storage for making copies of live, i.e., allocated, data. This is due to the fact that such collectors periodically copy all reachable objects into a second memory space so the first memory space can be reclaimed in its entirety.
- mark & sweep collectors employ a "collector” which synchronizes the launching of markers and sweepers for the purpose of garbage collection.
- the marker traverses all memory locations and "marks" those which are presently being used by an application (also alternatively referred to as the "mutator” herein and as wellknown in the garbage collection computing arts).
- objects which remain unmarked are available for reallocation.
- the sweeper follows the marker and places the free memory locations, i.e., unmarked objects, in a so called “free-list” from which the memory can be reallocated by the computer system.
- a disadvantage of mark & sweep garbage collection is that the collector must continually step through the entire set of free and in-use memory objects thereby making the total time required for garbage collection directly proportional to the number of the memory objects in the system.
- garbage collection routines In order to address the inherent costs of garbage collection techniques as described above, the developers of garbage collection routines have incorporated concurrency in their designs whereby garbage collection occurs contemporaneously with application execution, i.e., mutator execution. More particularly, concurrent garbage collection techniques fall generally into one of two classes: (1) variations on mark & sweep collectors, see, for example, E. W. Dijkstra et al., "On-the-fly garbage collection: An exercise in cooperation", Communications of the ACM, 21(11):966-975, November 1978 (hereinafter referred to as "Dijkstra"), and G. L.
- concurrent garbage collection techniques provide a level of marked improvement over non-concurrent garbage collection
- concurrent garbage collectors require substantial synchronization between the application, i.e., mutator, and the garbage collector to ensure data integrity and to avoid interference between the respective activities of the mutator and garbage collector.
- the Dijkstra collector a concurrent mark & sweep garbage collector (hereinafter referred to as "the Dijkstra collector") which employs a well-known tricolor abstraction scheme (see, for example, Dijkstra, supra. at pp. 969-972, and Jones et al., supra. at pp. 186-187) to distinguish presently allocated objects from garbage.
- conventional tricolor marking employs the following three colors: (1) black--indicates that the object is presently allocated and used; (2) gray--indicates that an object is in a transitional state and is in the process of being retained; and (3) white--indicates objects that are subject to collection, i.e., garbage.
- the Dijkstra collector at the beginning of the collection cycle uses the tricolor abstraction to color all of the objects in the root set (i.e., the beginning set of objects) the color gray.
- particular white objects are marked gray by the marker and all children, i.e., descendants attributable to a particular object, of the particular white object are colored gray.
- gray objects are generated by Dijkstra's collector these objects are queued for marking.
- objects which retain a white color during the collection cycle are designated as garbage at the end of the marker phase and therefore subject to collection.
- the interpretation of the colors white and black, respectively is reversed from that of the just prior garbage collection cycle.
- the reversal of the white and black colors occurs, in the Dijkstra collector, at the end of each collection cycle.
- the color gray and the interpretation of gray objects does not change during this transition in the Dijkstra collector and the sweeping phase of this collector must strictly follow the marking phase because of the fact that a white object's color may change (e.g., to gray and later to black) at any point in time during the marking phase.
- the Dijkstra collector requires that sweeping always follow marking because it is only at the end of the marking cycle that a determination can be ascertained at to whether certain objects, e.g., white objects, can be reclaimed as garbage.
- the Dijkstra collector requires so called "fine-grain synchronization" between the mutator and the collector. More particularly, such fine-grain synchronization is realized through the utilization of a write barrier which prevents the mutator from interfering with the collector during garbage collection. Thus, fine-grain synchronization insures that the mutator and collector do not simultaneously access and alter a common object.
- both the Queinnec collector and the Lamport collector rely significantly on the principles of the above-described Dijkstra collector but depart in one way from Dijkstra's collector by employing five colors to achieve their concurrency. As one might expect the introduction of five colors in these collector's color abstraction schemes increases the complexity of these two collectors.
- both the Queinnec collector and Lamport collector incorporate the so called "shade" atomic operation used by the Dijkstra collector. That is, the Queinnec collector and the Lamport collector each require frequent inter-processor synchronization amongst their respective marker and mutator during typical collection operations because either the marker or mutator can modify a color (i.e., any of the five colors in the abstraction) visible to the other. As will be appreciated, such inter-processor synchronization, i.e., fine-grain synchronization, comes at an increase in processing overhead.
- the Queinnec collector provides for concurrent threads of operation for the mutator, marker and sweeper thereby allowing for marking during sweeping.
- concurrency comes with a significant atomicity requirement.
- the notion of atomicity in the garbage collection context means that access to a shared memory variable, i.e., a memory location, is mutually exclusive. That is, if one thread, e.g., the mutator, has access to the variable, another thread, e.g., the marker, must wait until the first thread explicitly relinquishes its rights to the variable.
- the Queinnec collector utilizes atomic operations in the performance of mutation, marking and sweeping. For example, when an object in the Queinnec collector is being examined by the marker there is a lock placed on that object which prohibits access by the sweeper and/or mutator. More particularly, this collector requires multiple fine-grain synchronizations within a single mark or sweep step, and further requires that mutator operations occur atomically. Thus, in effect, these atomic operations act similar to that as the previously described write barrier and require a significant amount of processing overhead.
- the present invention provides a garbage collection technique for the concurrent operation of a mutator and garbage collector (e.g., marker and sweeper) without requiring fine-grain synchronization or atomicity amongst the mutator, marker and sweeper.
- a mutator and garbage collector e.g., marker and sweeper
- three threads are used for concurrently executing the mutator, marker and sweeper.
- Our inventive garbage collector operates through a series of so called epochs (i.e., individual garbage collection phases) wherein the collector operates in each epoch to concurrently (1) run the mutator; (2) mark all objects that were reachable (i.e., allocated) in the previous epoch with the present epoch's color; and (3) reclaim any objects marked as garbage.
- the object coloring scheme used in the invention eliminates the need for any fine-grain synchronization or atomicity by maintaining the invariant that the mutator and marker never encounters an object colored with the sweeper's color.
- the garbage collector's colors are remapped, i.e., exchanged.
- the sweeper color is remapped to the next epoch's mutator color
- the mutator color is remapped to the next epoch's marker color
- the marker color is remapped to the next epoch's sweeper color.
- Such remapping ensures that objects which are garbage will be detected and reclaimed by our collector without any fine-grain synchronization or atomicity between the mutator, marker and sweeper. Further, in accordance with the invention, only the marker may alter an object's assigned color during an epoch thereby eliminating any need for fine-grain synchronization or atomicity between the mutator, marker and sweeper.
- the marker is initialized with a color, i.e., the marker color, determined as a function of the current epoch's mutator color. Thereafter, the marker brings all reachable data, e.g., objects, from the prior epoch up to current status such that the data will be reachable by the mutator in the current epoch.
- reachable data e.g., objects
- the marker may alter the object's color thereby eliminating the need for fine-grain synchronization or atomicity.
- the sweeper during each epoch, is initialized with a color, i.e., the sweeper color, as function of the current epoch's color. Thereafter, the sweeper examines particular objects and, if the object carries a designation of the sweeper's color, the object is garbage and returned to the free-list for reallocation.
- a color i.e., the sweeper color
- FIG. 1 is an example of the transitions which occur for allocated and unallocated objects during garbage collection cycles in a prior art garbage collector which requires fine-grain synchronization;
- FIG. 2 is a flowchart showing steps for implementing garbage collection in accordance with the principles of the invention
- FIG. 3 represents pseudo-code for implementing an embodiment of the invention as shown in FIG. 2;
- FIG. 4 shows an illustrative collection of objects and their state transitions during garbage collection in accordance with the invention
- FIG. 5 represents pseudo-code for implementing a further embodiment of the invention which supports reference update
- FIG. 6 represents C computer source code for implementing an illustrative asynchronous write barrier for use in conjunction with the principles of the invention as shown in FIG. 2;
- FIG. 7 shows a block diagram of an illustrative computer system for using a garbage collector configured in accordance with the principles of the invention.
- the present invention provides a garbage collection technique for the concurrent operation of a mutator and garbage collector (e.g., marker and sweeper) without finegrain synchronization or atomicity amongst the mutator, marker and sweeper.
- a mutator and garbage collector e.g., marker and sweeper
- FIG. 1 is an example of the transitions which occur for allocated and unallocated objects during garbage collection cycles consistent with a prior art garbage collector, e.g. the Dijkstra collector, which requires fine-grain synchronization.
- This example employs the previously described well-known tricolor abstraction scheme, e.g., as employed in the Dijkstra collector.
- FIG. 1 shows the traversal of object transition states for an allocated (i.e., a so called "live" object) object example 100, and a series of so called “dead" objects 105, i.e., objects which are not currently in use.
- each object state carries the designation of a particular color, consistent with the conventional tricolor abstraction scheme, as assigned during the garbage collection process.
- the conventional tricolor abstraction scheme employs three colors, i.e., white, gray and black, for coloring objects during their different transitional states during the garbage collection process.
- live object 101 has a white object transition state 101-1 indicating that the object has a live state thereby meaning that the object is currently allocated by the mutator.
- object transition state 101-1 remains white during the initial stage of operations of marker 125.
- this tricolor abstraction scheme employs a particular object coloring mechanism during the garbage collection phases. That is, objects in the root set are first colored gray at the beginning of a garbage collection cycle. As will be appreciated, the root set is a set of objects from which all live objects are reachable. Thereafter, particular gray objects are colored, i.e., marked, black by the marker, and all objects which are descendants, i.e., children, of that particular black object are colored gray. As gray objects are generated during a garbage collection cycle, these objects are queued for marking. Those objects that retain their white color during a collection phase are designated as garbage at the end of the marking phase within a particular garbage collection cycle. Thereafter, the sweeper phase of the garbage collection cycle collects those objects designated as garbage.
- the current garbage collection cycle nears completion and just prior to entering the next garbage collection cycle the interpretation of the colors white and black, respectively is reversed.
- the color gray does not change between garbage collection cycles.
- the gray color is always used a transitional mechanism in this scheme.
- sweeping must strictly follow marking since a white object's color may change (e.g., to gray and later to black) at any point in the marking phase of the garbage collection cycle. Further aspects of the conventional tricolor coloring scheme are described below.
- live object 101 transitions from white (object transition state 101-2) to gray (object transition state 101-3) to black (object transition state 101-4) during the execution of marker 125. Thereafter, live object 101 retains its black color (transition state 101-5) throughout the execution of sweeper 135. As discussed above, at the end of garbage collection cycle 110, the garbage collector's colors are remapped, that is, the interpretation of the colors white and black, respectively, is reversed. Thus, as live object 101 enters the next garbage collection cycle 120 with a color black (object transition state 101-6) it will be marked gray (object transition state 101-7) then marked white (object transition state 101-8) by marker 125.
- garbage collection cycle 120 a white color now designates a live object while a black color now designates garbage. Thereafter, as sweeper 135 executes in garbage collection cycle 120, live object 101 retains its white color (object transition state 101-9) and is not subject to reclamation.
- FIG. 1 also shows an example of the traversal of object transition states for a series dead objects 105.
- dead object 102 has a white object transition state 102-1 just prior to entering garbage collection cycle 110.
- dead object 102 retains its white color (white object transition state 102-2) through the execution of marker 125 and is later reclaimed at, e.g., white object transition state 102-3 by sweeper 135.
- dead object 103 having black object transition state 103-1 has remained "unmarked" during garbage collection cycle 110 and will be subject to reclamation in the next garbage collection cycle 120.
- dead object 103 begins garbage collection cycle 120 with black object transition state 103-2. With the interpretation of colors being remapped, i.e., reversed, for this cycle, the object will retain its black color (i.e., black carries a dead object designation in this cycle) throughout garbage collection cycle 120. Thereafter, sweeper 135 reclaims dead object 103 at, e.g., black object transition state 103-3.
- the operations of the prior art garbage collector of FIG. 1 require fine-grain synchronization between the mutator and the collector. More particularly, such fine-grain synchronization is realized through the utilization of a write barrier which ensures that the mutator and collector do not simultaneously access and alter a common object.
- the collector of FIG. 1 requires that sweeping always follow marking because it is only at the end of the marking cycle that a determination can be made as to whether certain objects can be reclaimed.
- the present invention provides an efficient garbage collection technique which eliminates the need for fine-grain synchronization or atomicity during garbage collection.
- conventional multiprocessor computer systems have an inherent form of memory atomicity which manifests itself in such systems as an atomic write operation.
- the computer's memory system performs machine-word writes atomically, that is, if memory location "M" holds value "x" before value "y" is written to M, any memory reads of location M will return either value x or value y, but never an intermediate value, e.g., the high order bits of x and the lower order bits of y.
- Our garbage collection technique recognizes that this inherent atomic write operation exists in such memory systems and the invention is not directed at the elimination of such inherent atomic write operations. Rather the advantages of the invention are the elimination of fine-grain synchronization or atomicity during garbage collection.
- FIG. 2 shows a flowchart of illustrative steps 200 for implementing garbage collection in accordance with the principles of the invention.
- Our garbage collection technique uses a conventional free-list allocator which maintains a list of blocks of memory of, e.g., in a computer system such as shown in FIG. 7 and as will be discussed later herein.
- initialization of the free-list allocator (block 205) occurs such that the free-list allocator divides the available memory for free-list allocation into one or more so called "free blocks".
- the identified free blocks are linked during the initialization (block 205) to form a so called free list.
- a request for storage (e.g., access to an object) by, e.g., an executing application (hereinafter alternatively referred to as “the mutator” or “mutator process") will cause a scan of the free list to occur to determine if there is a memory block available to satisfy the storage request. If such a memory block presently is available, the allocator will remove the particular block from the free-list and give it, i.e., provide access to, the mutator. As will be further discussed below, when the allocated block is identified by the sweeper of our garbage collector, the block is again placed on the free-list for allocation.
- our garbage collector operates in so called epochs.
- an epoch designates a particular time sequence during which garbage collection will occur in accordance with the principles of the invention. As will be appreciated, there may be more than one epoch sequence during the execution of an application program and the corresponding garbage collection.
- each epoch creates concurrent threads (block 210) for execution of the mutator, marker (hereinafter alternatively referred to as “the marker” or “marker process”) and sweeper (hereinafter alternatively referred to as “the sweeper” or “sweeper process”).
- the mutator hereinafter alternatively referred to as "the marker” or “marker process”
- sweeper hereinafter alternatively referred to as "the sweeper” or “sweeper process”
- a series of colors is employed, in particular three colors, which facilitate the collection of garbage without fine-grain synchronization or atomicity. The way in which our invention achieves this result will be become apparent from the detailed discussion below.
- a current epoch color is assigned (block 215), illustratively, in accordance with the function:
- the concurrent execution of the threads i.e., the mutator process, the marker process and the sweeper process, begins (block 220).
- the mutator, marker and sweeper are all initialized with particular colors (blocks 225, 230 and 235, respectively), each of which is defined as a function of the current epoch color.
- the mutator is initialized (block 225) with a color (hereinafter "the mutator color") which is the same as the current epoch color determined, illustratively, in accordance with COLOR(epoch), where the variable "epoch” is assigned an integer value.
- the function mapping e.g., COLOR(epoch)
- COLOR(i) is to be understood as an instantiation of the previously described COLOR(i) function, and hereinafter we will refer to other such instantiations of the function COLOR(i) in the same function mapping terms.
- the mutator requires access to and use of certain objects during the course of its mutation (block 290), i.e., execution. As such, the mutator allocates particular objects for which it requires access from the free-list allocator. Objects which are allocated by the mutator during a particular epoch are designated with the mutator color. In accordance with the preferred embodiment of the invention, objects designated with the mutator color retain this particular color through at least the end of the current epoch. Significantly, in accordance with the invention, the mutator is unaware of the color designations associated with the marker and/or sweeper. That is, the mutator is only concerned with the allocation of objects using the mutator's designated color.
- the marker process and the sweeper process are the marker process and the sweeper process.
- the marker is initialized with its own color (block 230).
- the marker color is initialized with a color (hereinafter "the marker color") determined as a function of the current epoch's mutator color.
- the marker's color is determined in accordance with the function mapping COLOR(epoch-1).
- the variable "epoch” is an integer variable holding the current epoch number.
- COLOR(i) is a function where i is a variable.
- the marker brings all reachable objects from the prior epoch up to current status. That is, the marker brings all objects which are reachable, i.e., still in use, by the mutator current by utilizing the marker color such that the data will be reachable by the mutator for use in, e.g., new data structures required by the continued execution of the mutator.
- the marker may thereafter alter the object's color thereby eliminating the need for fine-grain synchronization or atomicity between the mutator and marker.
- the marker recursively traverses all live objects (block 240), as described above, which are reachable from the mutator's root set of the previous epoch. Thereafter, the root set is copied from the mutator at the end of the current epoch for use by the marker in the next epoch. More particularly, in accordance with invention, the marker can reach objects that have either the previous epoch's color (hereinafter alternatively referred to as the function mapping "COLOR(epoch-1)”) or the current epoch's color (i.e., the mutator color as determined by the function mapping COLOR(epoch)).
- one of two possible operations occurs: (1) if the current designation of the object is the marker's color, the object's color is changed to the mutator's color and all other objects reachable from that object, e.g., children are recursively marked in a similar fashion; otherwise (2) if the object's color is the mutator's color, the object's color remains unchanged. In this case, the object was previously examined, during the current epoch, by the marker and this object along with its children are known to have been previously marked.
- the marker when the marker completes its traversal of live objects (block 240) as described above, an invariant holds that all reachable objects have the mutator color.
- the marker will not encounter any objects colored with the sweeper's color (as further described below) because at the end of the previous epoch (and corresponding previous marking phase) all reachable objects must have a designation in conformance with the marker's color. The net result is that the marker's only visible effect is to change colors of objects having the previous epoch's color.
- the sweeper process is initialized (block 235) with a so called sweeper color.
- the sweeper color is derived as a function of the current epoch color, and in particular the sweeper color is illustratively derived using the function mapping COLOR(epoch-2).
- the sweeper traverses every object (block 245) in memory, e.g., the memory of the computer system executing the mutator. If an object has the current sweeper color that particular object may be collected, deallocated, and returned to the free-list.
- the reclamation of such an object is safe because neither the mutator nor the marker can reach it at that time, i.e., in the current epoch. Otherwise, if the object has the mutator's color, e.g., COLOR(epoch), or the previous epoch's color, e.g., COLOR(epoch-1), that particular object is skipped due to the fact that it is potentially in use and should not be deallocated.
- the mutator's color e.g., COLOR(epoch)
- the previous epoch's color e.g., COLOR(epoch-1
- objects having the marker's color e.g., COLOR(epoch-1) will either be marked with the current epoch's color, e.g., COLOR (epoch), during the current epoch if reachable from the root set, or their color will remain unchanged signifying that the object has become garbage and can be later detected by the sweeper in the next epoch for reclamation as described above.
- the current epoch's color e.g., COLOR (epoch)
- the only color that can change during a particular sweep is a marker color changing to a mutator color in accordance with the operations described above wherein only the marker may change an object's color.
- each epoch e.g., epoch i
- all objects colored by the value COLOR(i) are live because they were allocated by the mutator in the current epoch or were marked by the marker with COLOR(i) because they were reachable from the last root set.
- Further objects designated with the color defined by the value COLOR(i-1) may or may not be encountered at the end of the current epoch by the marker and marked with COLOR(i) depending upon whether or not the objects are reachable from the root set.
- objects designated with the color having value COLOR(i-2) will be reclaimed by the sweeper during the current epoch as these objects were not marked in the previous epoch since they were unreachable to the marker, and in turn, unreachable to the mutator as well.
- the barrier synchronization is a "start-up" mechanism for individual garbage collection cycles to ensure that the mutator, marker and sweeper begin their concurrent operation at a common execution point. For example, the barrier synchronization may occur only after complete marker and sweeper passes have been completed.
- each of the concurrently executing processes enters the beginning of the barrier synchronization (block 250) when they complete their collection phase and the barrier is not exited, i.e., each thread in the barrier remains idle, until all threads have checked into the barrier.
- all write operations (block 255) by all three threads must be completed before the barrier synchronization ends (block 260) to ensure that all objects which have been recolored by the marker during the current epoch are visible to the sweeper in the next epoch.
- the mutator thread is suspended (block 265) and the mutator's root set is copied and saved (block 270) for use in marking in the next epoch.
- the thread state is reset (block 275) and the colors are remapped (block 280).
- remapping is achieved using an epoch counter and the COLOR(i) function to map an epoch to a color.
- the color remapping occurs at the boundaries between consecutive epochs.
- our garbage collector's colors are exchanged as follows: COLOR(epoch) is remapped as COLOR(epoch-1), COLOR(epoch-1) is remapped as COLOR(epoch-2), and COLOR(epoch-2) is remapped as COLOR(epoch).
- the next epoch begins (block 285).
- FIG. 3 shows pseudo-code routine 300 for implementing a garbage collector in accordance with the principles of the invention.
- pseudo-code can be converted in a conventional manner into source code using any of a number of standard computer programming languages for actual execution.
- C programming language see, for example, B. W. Kernighan et al., The C Programming Language, Second Edition, Prentice Hall, Englewood Cliffs, N.J., 1988
- computer source code may be executed, e.g., in the computer system shown in FIG. 7, for realizing the advantages of the invention.
- lines 301 through 303 are variable declaration statements for defining particular variables and relationships within pseudo-code routine 300.
- Lines 304 and 314 are well-known delimiters for defining a function as defined in lines 305 through 313 of FIG. 3.
- lines 304 through 314 are executed, on an epoch-by-epoch basis, for providing a garbage collector in accordance with the principles of the invention as described previously.
- lines 305 through 307 create the three concurrent threads of execution for the mutator, marker and sweeper, assign the initial colors thereto, and provide on an epoch-by-epoch basis the concurrent operation of: (i) the execution of the mutator; (ii) the execution of the marker for marking, with the current epoch's color all objects that were reachable in the previous epoch; and (iii) the reclaiming of any objects by the sweeper with the mutator color of two prior epochs.
- line 307 provides for the barrier synchronization between the marker and sweeper.
- Line 310 suspends the current execution of the mutator in anticipation of the next epoch, line 311 resets the root set, line 312 deletes the current threads used for the mutator, marker and sweeper, and line 313 advances the routine for providing garbage collection in the next epoch.
- FIG. 4 shows an illustrative collection of objects and their state transitions during garbage collection in accordance with the invention. More particularly, FIG. 4 shows an example of the traversal through a series of object transition states for a live object example 400, and a series of dead objects 405.
- FIG. 4 shows an illustration of the object color designations in accordance with the invention:
- epoch i white objects have the marker color, i.e., COLOR(i-1), and gray objects have the mutator color, i.e., COLOR(i).
- the sweeper will reclaim those objects having COLOR(i-2), i.e., black.
- the illustrative examples of the invention herein employ black, white and gray colors for depicting the state of the objects, the selection of such designations is merely illustrative for simplicity of explanation herein and not critical to the invention.
- the colors could be alternatively designated red, white and blue, or, zero, one and two.
- the only necessity is to have some sort of distinction for the transitional phases of an object, e.g., from allocated to unallocated.
- the object color interpretation in accordance with the invention is distinct and enables the delivery of garbage collection without the use of fine-grain synchronization or atomicity.
- live object example 400 a series of object transition states 401-1 through 401-10 are shown which depict the different transitional states of live object 401, in accordance with the invention, through three consecutive epochs 410, 415, and 420, respectively.
- live object 401 just prior to entering the first epoch 410 (illustrative designated as epoch i), live object 401 has a white object transition state 401-1 indicating that the object has a live state thereby meaning that the object is currently allocated by the mutator.
- the white color designation carried by live object 401 is derived, illustratively, as a function of the epoch number i using COLOR(i-1).
- object transition state 401-2 As live object 401 enters epoch 410 its object transition state 401-2 initially remains white.
- marker 425 and sweeper 430 execute concurrently during each of epoch 410, 415, and 420, respectively. Since it is live, object transition state 401-2 is visible to marker 425 during epoch 410 and is therefore marked by marker 425 with the mutator color designation as determined, illustratively, by COLOR(i), as shown by gray object transition state 401-3.
- the current mutator color in epoch 410 is also the color determined, illustratively, by COLOR(i).
- sweeper 430 is looking for black colored objects for reclamation as garbage since black is the current sweeper color as determined, illustratively, by COLOR(i-2). Live object 401 retains its gray designation through the end of epoch 410, thereby not subject to reclamation by sweeper 430, as shown by gray object state transition 401-4.
- live object 401 Upon entering the next epoch, e.g., epoch 415 (illustratively designated epoch i+1), live object 401 initially retains its gray designation (gray object transition state 401-5) from the end of the previous epoch, i.e., epoch 410. However, in accordance the invention, live object 401 is colored black (black object transition state 401-6) by marker 425 during epoch 415, the color being determined, illustratively, by COLOR(i+1), which is the mutator color designation of the current epoch.
- sweeper 430 during epoch 415, is looking for white colored objects for reclamation as garbage since white is now the current sweeper color as determined, illustratively, by COLOR(i-2).
- live object 401 retains its black designation through the end of epoch 415, thereby not subject to reclamation by sweeper 430, as shown illustratively by black object transition state 401-7.
- live object 401 upon entering the next epoch, e.g. epoch 420 (illustratively designated epoch i+2), live object 401 initially retains its black designation (black object transition state 401-8) from the end of the previous epoch, i.e., epoch 415, because the current marker color is black. Thereafter, in accordance the invention, live object 401 is colored white (object transition state 401-9) by marker 425 during epoch 420, the color being determined, illustratively, by COLOR(i+2) which is the mutator color of the current epoch.
- Sweeper 430 is now looking for gray colored objects for reclamation as garbage since gray is now the current sweeper color as determined, illustratively, by COLOR(i-2).
- live object 401 retains its white designation through the end of epoch 420, thereby not subject to reclamation by sweeper 430, as shown by white object state transition 401-10.
- live object 401 will carry its white designation to the next epoch in accordance with the invention.
- FIG. 4 also shows the traversal of object transition states for a series of dead objects 405. As above, the same three consecutive epochs are depicted, 410, 415, and 420, respectively.
- dead object 405 has a black object transition state 405-1 just prior to entering epoch 410. Being dead, dead object 405 retains its black color (black object transition state 405-2) through the execution of marker 425 and is later reclaimed at, e.g., black object transition state 405-3 by sweeper 430.
- sweeper 430 is currently looking for black colored objects for reclamation as garbage since black is the current sweeper color as determined, illustratively, by COLOR(i-2).
- dead object 406 having white object transition state 406-1 has remained "unmarked" during epoch 410 and is subject to reclamation in the next epoch.
- our garbage collector's colors are remapped, i.e., exchanged.
- black is remapped as white
- white is remapped as gray
- gray is remapped as black.
- an object with COLOR(i-2) entering epoch i will be reclaimed by that epoch's sweeper.
- an object with COLOR(i-1) entering epoch i+1 is reclaimed by that epoch, as is an object with COLOR(i) entering epoch i+2.
- dead object 405 enters epoch 410, e.g., epoch i, having black object transition state 405-1 with the color black being determined, illustratively, by COLOR(i-2).
- epoch 410 e.g., epoch i
- dead object 405 will be subject to reclamation by sweeper 430 at, e.g., black object transition state 405-3.
- dead object 407 having gray object transition states 407-1 through 407-3 with the color gray being determined, illustratively, by COLOR(i), upon entering and during epoch 420, e.g., epoch i+2, is subject to reclamation by sweeper 430.
- the functionality and advantages of our garbage collector can be extended to support so called "reference update”.
- "state" in the form of mutable references poses certain known problems for concurrent garbage collectors since a subgraph G' of a dynamic state graph G may become temporarily disconnected from G. Since a conventional collector's marking phase traverses G, subgraph G' may not be properly marked during garbage collection. Yet G' may later be reconnected during subsequent garbage collection cycles to G in a location already visited by the marker. In such a case, subgraph G' has become inaccessible to the marker before being marked. The result is that subgraph G''s data is incorrectly reclaimed by the sweeper while actually still live, i.e., allocated and not garbage.
- the mutator fetches the content v (v being a subgraph) of reference cell r.
- the mutator retains v, e.g., in a register, before updating r with v' (v' being a subgraph). That is, the mutator redirects r's link from pointing to v to pointing to v'.
- r may have held the only reference to v and the marker may not have reached and marked v, through r, before the mutator replaced it with v'.
- our garbage collector calls for the mutator to communicate the replaced content v as a root to the concurrently running marker thread. That is, the marker will possess this new root set before the next epoch, e.g., epoch i+1, can begin.
- the collector requires that the replaced object be marked as opposed to the target of the redirection being marked.
- FIG. 5 shows pseudo-code routine 500 for implementing a further embodiment of the invention to support reference update.
- pseudo-code routine 500 can be converted in a conventional manner into source code using any of a number of standard computer programming languages.
- the mutator places the current content of the reference in a so called "store set.”
- the marker marks particular elements in the store set in the same manner as it marks roots in the root set.
- pseudo-code routine 500 of FIG. 5 is similar to pseudo-code routine 300 of FIG. 3, with the addition of code block 510 and line 511 to support the reference update aspect of this embodiment of the invention.
- source code derived from pseudo-code routine 500 may be executed in the computer system of FIG. 7 for realizing a garbage collector in accordance with the invention.
- the invention herein facilitates concurrent garbage collection without the need for fine-grain synchronization or atomicity between the mutator, marker and sweeper.
- the store set is implemented as a non-blocking store list. That is, in accordance with a further embodiment of the invention, during the garbage collection process with respect to a particular epoch, the mutator constructs a linked list of store roots such that new store roots are inserted at the head of the linked list. The marker traverses the linked list until it revisits a position in the linked list that is previously visited.
- FIG. 6 represents illustrative C computer source code 600 for implementing the illustrative asynchronous write barrier in the above described embodiment of the invention.
- source code 600 provides non-blocking set functions for realizing the illustrative asynchronous write barrier without any explicit synchronization even though the mutator may insert roots, e.g., code block 615, to the root set while the marker concurrently removes roots, e.g., code block 610.
- FIG. 7 shows a block diagram of an illustrative computer system 700 using a garbage collector in accordance with the principles of the invention.
- computer system 700 has operating system 710 with garbage collector 720, configured in accordance with the principles of the invention, and memory routines 730 for providing memory allocation in well-known manners.
- memory routines 730 include free-list allocator 740 for use by garbage collector 720 and memory 770 in implementing various embodiments of the invention as described previously.
- Central processing unit (CPU) 750 is illustrative of any microprocessor for executing application programs such as application program 780.
- computer system 700 is illustratively shown having a single CPU, e.g., CPU 750, it will be understood that the principles of the invention are not limited to a single CPU and are equally applicable in a computer system having more than one CPU.
- memory 770 is used for storing, e.g., objects accessed during the execution of application program 780.
- bus 790 is used for, among other things, input and output throughout the computer system 700 and including user interface 760 which provides the interface in a conventional manner to users of computer system 700.
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
Description
Claims (12)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/987,030 US6052699A (en) | 1996-12-11 | 1997-12-10 | Garbage collection without fine-grain synchronization |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US3330396P | 1996-12-11 | 1996-12-11 | |
US08/987,030 US6052699A (en) | 1996-12-11 | 1997-12-10 | Garbage collection without fine-grain synchronization |
Publications (1)
Publication Number | Publication Date |
---|---|
US6052699A true US6052699A (en) | 2000-04-18 |
Family
ID=26709528
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US08/987,030 Expired - Lifetime US6052699A (en) | 1996-12-11 | 1997-12-10 | Garbage collection without fine-grain synchronization |
Country Status (1)
Country | Link |
---|---|
US (1) | US6052699A (en) |
Cited By (43)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6289360B1 (en) * | 1998-10-07 | 2001-09-11 | International Business Machines Corporation | Method and system for eliminating synchronization between sweep and allocate in a concurrent garbage collector |
US20010023478A1 (en) * | 2000-03-17 | 2001-09-20 | Toshihiro Ozawa | Device and method for managing memory resources |
US6317816B1 (en) * | 1999-01-29 | 2001-11-13 | International Business Machines Corporation | Multiprocessor scaleable system and method for allocating memory from a heap |
US6349314B1 (en) * | 1999-09-29 | 2002-02-19 | Motorola, Inc. | Adaptive scheduler for mark and sweep garbage collection in interactive systems |
US20020052926A1 (en) * | 1999-02-22 | 2002-05-02 | Sun Microsystems, Inc. | Thread suspension system and method using trapping instructions |
US20020087590A1 (en) * | 2000-12-11 | 2002-07-04 | International Business Machines Corporation | Concurrent collection of cyclic garbage in reference counting systems |
US6438560B1 (en) | 1999-09-16 | 2002-08-20 | International Business Machines Corporation | Reuse of immutable objects during object creation |
US20030005025A1 (en) * | 2001-06-27 | 2003-01-02 | Shavit Nir N. | Load-balancing queues employing LIFO/FIFO work stealing |
US6526421B1 (en) * | 1999-03-31 | 2003-02-25 | Koninklijke Philips Electronics N.V. | Method of scheduling garbage collection |
US20030069905A1 (en) * | 2000-07-31 | 2003-04-10 | Microsoft Corporation | Method and system for concurrent garbage collection |
US6684393B1 (en) | 1999-01-29 | 2004-01-27 | International Business Machines Corporation | Compilation method and system to reuse memory storage instead of allocating it |
US20040040018A1 (en) * | 2002-08-22 | 2004-02-26 | Internatinal Business Machines Corporation | Apparatus and method for removing elements from a linked list |
US6823351B1 (en) * | 2000-05-15 | 2004-11-23 | Sun Microsystems, Inc. | Work-stealing queues for parallel garbage collection |
US6826583B1 (en) | 2000-05-15 | 2004-11-30 | Sun Microsystems, Inc. | Local allocation buffers for parallel garbage collection |
US6845385B1 (en) * | 1994-07-13 | 2005-01-18 | Object Technology Licensing Corp. | Real-time computer “garbage collector” |
US20050021576A1 (en) * | 2003-07-23 | 2005-01-27 | International Business Machines Corporation | Mostly concurrent garbage collection |
US6862674B2 (en) * | 2002-06-06 | 2005-03-01 | Sun Microsystems | Methods and apparatus for performing a memory management technique |
US6973457B1 (en) | 2002-05-10 | 2005-12-06 | Oracle International Corporation | Method and system for scrollable cursors |
US20060026183A1 (en) * | 2004-07-27 | 2006-02-02 | Texas Instruments Incorporated | Method and system provide concurrent access to a software object |
US20060031844A1 (en) * | 2004-06-04 | 2006-02-09 | David Dice | Techniques for accessing a shared resource using an improved synchronization mechanism |
US7089331B1 (en) | 1998-05-29 | 2006-08-08 | Oracle International Corporation | Method and mechanism for reducing client-side memory footprint of transmitted data |
US7103590B1 (en) * | 2001-08-24 | 2006-09-05 | Oracle International Corporation | Method and system for pipelined database table functions |
US20070288718A1 (en) * | 2006-06-12 | 2007-12-13 | Udayakumar Cholleti | Relocating page tables |
US20070288719A1 (en) * | 2006-06-13 | 2007-12-13 | Udayakumar Cholleti | Approach for de-fragmenting physical memory by grouping kernel pages together based on large pages |
US20080005521A1 (en) * | 2006-06-30 | 2008-01-03 | Udayakumar Cholleti | Kernel memory free algorithm |
US20080005517A1 (en) * | 2006-06-30 | 2008-01-03 | Udayakumar Cholleti | Identifying relocatable kernel mappings |
US20080005495A1 (en) * | 2006-06-12 | 2008-01-03 | Lowe Eric E | Relocation of active DMA pages |
US7389284B1 (en) | 2000-02-29 | 2008-06-17 | Oracle International Corporation | Method and mechanism for efficient processing of remote-mapped queries |
US20080281885A1 (en) * | 2007-05-08 | 2008-11-13 | Microsoft Corporation | Interleaved garbage collections |
US7475397B1 (en) | 2004-07-28 | 2009-01-06 | Sun Microsystems, Inc. | Methods and apparatus for providing a remote serialization guarantee |
US20090112953A1 (en) * | 2007-10-30 | 2009-04-30 | Eric Lawrence Barsness | Enhanced garbage collection in a multi-node environment |
US7594234B1 (en) | 2004-06-04 | 2009-09-22 | Sun Microsystems, Inc. | Adaptive spin-then-block mutual exclusion in multi-threaded processing |
US7610351B1 (en) | 2002-05-10 | 2009-10-27 | Oracle International Corporation | Method and mechanism for pipelined prefetching |
US7636745B1 (en) * | 2004-03-12 | 2009-12-22 | Sun Microsystems, Inc. | Concurrent-marking-initiation heuristic |
US20100114997A1 (en) * | 2008-10-30 | 2010-05-06 | International Business Machines Corporation | Allocation cache premarking for snap-shot-at-the-beginning concurrent mark-and-sweep collector |
US20100153675A1 (en) * | 2008-12-12 | 2010-06-17 | Microsoft Corporation | Management of Native Memory Usage |
US7831961B1 (en) | 1999-02-22 | 2010-11-09 | Oracle America, Inc. | Cooperative preemption mechanism for garbage-collected multi-threaded computation |
US7844499B2 (en) | 2005-12-23 | 2010-11-30 | Sharp Electronics Corporation | Integrated solar agent business model |
US8452938B1 (en) | 2004-12-30 | 2013-05-28 | Azul Systems, Inc. | Garbage collection with memory quick release |
US8738877B2 (en) | 2011-12-14 | 2014-05-27 | Advance Micro Devices, Inc. | Processor with garbage-collection based classification of memory |
US10289728B2 (en) * | 2006-05-15 | 2019-05-14 | Avaya Inc. | Garbage collection of persistent objects with dynamic multikeys |
US20190146917A1 (en) * | 2013-06-22 | 2019-05-16 | Microsoft Technology Licensing, Llc | Log-structured storage for data access |
US12019541B2 (en) * | 2022-10-17 | 2024-06-25 | Oracle International Corporation | Lazy compaction in garbage collection |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5088036A (en) * | 1989-01-17 | 1992-02-11 | Digital Equipment Corporation | Real time, concurrent garbage collection system and method |
US5293614A (en) * | 1991-04-08 | 1994-03-08 | Texas Instruments Incorporated | System and method for hard real-time garbage collection requiring a write barrier but no read barrier |
US5355483A (en) * | 1991-07-18 | 1994-10-11 | Next Computers | Asynchronous garbage collection |
US5485613A (en) * | 1991-08-27 | 1996-01-16 | At&T Corp. | Method for automatic memory reclamation for object-oriented systems with real-time constraints |
US5535390A (en) * | 1994-07-22 | 1996-07-09 | Hildebrandt; Thomas H. | Method for reusing temporaries and reclaiming shared memory |
-
1997
- 1997-12-10 US US08/987,030 patent/US6052699A/en not_active Expired - Lifetime
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5088036A (en) * | 1989-01-17 | 1992-02-11 | Digital Equipment Corporation | Real time, concurrent garbage collection system and method |
US5293614A (en) * | 1991-04-08 | 1994-03-08 | Texas Instruments Incorporated | System and method for hard real-time garbage collection requiring a write barrier but no read barrier |
US5355483A (en) * | 1991-07-18 | 1994-10-11 | Next Computers | Asynchronous garbage collection |
US5485613A (en) * | 1991-08-27 | 1996-01-16 | At&T Corp. | Method for automatic memory reclamation for object-oriented systems with real-time constraints |
US5535390A (en) * | 1994-07-22 | 1996-07-09 | Hildebrandt; Thomas H. | Method for reusing temporaries and reclaiming shared memory |
Non-Patent Citations (14)
Title |
---|
C. Queinnec, B. Beaudoing, J.P. Queille, "Mark During Sweep rather than Mark Then Sweep", Parle '89, LNCS 365, Springer-Verlag, Jun. 1989. |
C. Queinnec, B. Beaudoing, J.P. Queille, "Mark During Sweep rather than Mark Then Sweep", Parle, pp. 224-237, 1989. |
C. Queinnec, B. Beaudoing, J.P. Queille, Mark During Sweep rather than Mark Then Sweep , Parle , pp. 224 237, 1989. * |
C. Queinnec, B. Beaudoing, J.P. Queille, Mark During Sweep rather than Mark Then Sweep , Parle 89 , LNCS 365, Springer Verlag, Jun. 1989. * |
E. W. Dijkstra, L.Lamport, A. J. Martin, C.S. Scholten and E.F.F.M. Steffens, "On-the-Fly Garbage Collection: An Exercise in Cooperation," Communications of the ACM, pp. 966-975, vol. 21, N. 11, Nov. 1978. |
E. W. Dijkstra, L.Lamport, A. J. Martin, C.S. Scholten and E.F.F.M. Steffens, On the Fly Garbage Collection: An Exercise in Cooperation, Communications of the ACM , pp. 966 975, vol. 21, N. 11, Nov. 1978. * |
G. L. Steele, Jr., "Multiprocessing Compactifying Garbage Collection", Communications of the ACM, pp. 495-508, vol. 18, No. 9, Sep. 1975. |
G. L. Steele, Jr., Multiprocessing Compactifying Garbage Collection , Communications of the ACM , pp. 495 508, vol. 18, No. 9, Sep. 1975. * |
H. G. Baker, Jr. "List Processing in Real Time on a Serial Computer", Communications of the ACM, pp. 280-294, vol. 21, No. 4, Apr. 1978. |
H. G. Baker, Jr. List Processing in Real Time on a Serial Computer , Communications of the ACM , pp. 280 294, vol. 21, No. 4, Apr. 1978. * |
L. Lamport, "Garbage Collection With Multiple Processes: An Exercise in Parallelism" Proceedings of the International Conference on Parallel Processing, pp. 50-54, Aug. 1976. |
L. Lamport, Garbage Collection With Multiple Processes: An Exercise in Parallelism Proceedings of the International Conference on Parallel Processing, pp. 50 54, Aug. 1976. * |
P. R. Wilson, "Uniprocessor Garbage Collection Techniques", International Workshop on Memory Management, Springer-Verlag, 1992. |
P. R. Wilson, Uniprocessor Garbage Collection Techniques , International Workshop on Memory Management , Springer Verlag, 1992. * |
Cited By (72)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6845385B1 (en) * | 1994-07-13 | 2005-01-18 | Object Technology Licensing Corp. | Real-time computer “garbage collector” |
US7089331B1 (en) | 1998-05-29 | 2006-08-08 | Oracle International Corporation | Method and mechanism for reducing client-side memory footprint of transmitted data |
US8825805B2 (en) | 1998-05-29 | 2014-09-02 | Oracle International Corporation | Method and mechanism for reducing client-side memory footprint of transmitted data |
US9244938B2 (en) | 1998-05-29 | 2016-01-26 | Oracle International Corporation | Method and mechanism for reducing client-side memory footprint of transmitted data |
US6289360B1 (en) * | 1998-10-07 | 2001-09-11 | International Business Machines Corporation | Method and system for eliminating synchronization between sweep and allocate in a concurrent garbage collector |
GB2349719B (en) * | 1998-10-07 | 2003-07-09 | Ibm | Method and system for eliminating synchronization between sweep and allocate in a concurrent garbage collector |
US6684393B1 (en) | 1999-01-29 | 2004-01-27 | International Business Machines Corporation | Compilation method and system to reuse memory storage instead of allocating it |
US6317816B1 (en) * | 1999-01-29 | 2001-11-13 | International Business Machines Corporation | Multiprocessor scaleable system and method for allocating memory from a heap |
US7831961B1 (en) | 1999-02-22 | 2010-11-09 | Oracle America, Inc. | Cooperative preemption mechanism for garbage-collected multi-threaded computation |
US20020052926A1 (en) * | 1999-02-22 | 2002-05-02 | Sun Microsystems, Inc. | Thread suspension system and method using trapping instructions |
US7013454B2 (en) * | 1999-02-22 | 2006-03-14 | Sun Microsystems, Inc. | Thread suspension system and method using trapping instructions |
US6526421B1 (en) * | 1999-03-31 | 2003-02-25 | Koninklijke Philips Electronics N.V. | Method of scheduling garbage collection |
US6438560B1 (en) | 1999-09-16 | 2002-08-20 | International Business Machines Corporation | Reuse of immutable objects during object creation |
US6349314B1 (en) * | 1999-09-29 | 2002-02-19 | Motorola, Inc. | Adaptive scheduler for mark and sweep garbage collection in interactive systems |
US7389284B1 (en) | 2000-02-29 | 2008-06-17 | Oracle International Corporation | Method and mechanism for efficient processing of remote-mapped queries |
US20010023478A1 (en) * | 2000-03-17 | 2001-09-20 | Toshihiro Ozawa | Device and method for managing memory resources |
US6618738B2 (en) * | 2000-03-17 | 2003-09-09 | Fujitsu Limited | Device and method for managing memory resources by using parallel-type garbage collection |
US6823351B1 (en) * | 2000-05-15 | 2004-11-23 | Sun Microsystems, Inc. | Work-stealing queues for parallel garbage collection |
US6826583B1 (en) | 2000-05-15 | 2004-11-30 | Sun Microsystems, Inc. | Local allocation buffers for parallel garbage collection |
US7640544B2 (en) | 2000-05-15 | 2009-12-29 | Sun Microsystems, Inc. | Work stealing queues for parallel garbage collection |
US20030069905A1 (en) * | 2000-07-31 | 2003-04-10 | Microsoft Corporation | Method and system for concurrent garbage collection |
US7310655B2 (en) * | 2000-07-31 | 2007-12-18 | Microsoft Corporation | Method and system for concurrent garbage collection |
US8126940B2 (en) * | 2000-12-11 | 2012-02-28 | International Business Machines Corporation | Concurrent collection of cyclic garbage in reference counting systems |
US20020087590A1 (en) * | 2000-12-11 | 2002-07-04 | International Business Machines Corporation | Concurrent collection of cyclic garbage in reference counting systems |
US7216136B2 (en) * | 2000-12-11 | 2007-05-08 | International Business Machines Corporation | Concurrent collection of cyclic garbage in reference counting systems |
US20120131070A1 (en) * | 2000-12-11 | 2012-05-24 | International Business Machines Corporation | Concurrent Collection of Cyclic Garbage in Reference Counting Systems |
US20070185943A1 (en) * | 2000-12-11 | 2007-08-09 | International Business Machines Corporation | Concurrent Collection of Cyclic Garbage in Reference Counting Systems |
US8782104B2 (en) * | 2000-12-11 | 2014-07-15 | International Business Machines Corporation | Processing changes to reference counts associated with an object in reference counting systems |
US20080235309A1 (en) * | 2000-12-11 | 2008-09-25 | International Business Machines Corporation | Concurrent Collection of Cyclic Garbage in Reference Counting Systems |
US7103887B2 (en) | 2001-06-27 | 2006-09-05 | Sun Microsystems, Inc. | Load-balancing queues employing LIFO/FIFO work stealing |
US20030005025A1 (en) * | 2001-06-27 | 2003-01-02 | Shavit Nir N. | Load-balancing queues employing LIFO/FIFO work stealing |
US7103590B1 (en) * | 2001-08-24 | 2006-09-05 | Oracle International Corporation | Method and system for pipelined database table functions |
US6973457B1 (en) | 2002-05-10 | 2005-12-06 | Oracle International Corporation | Method and system for scrollable cursors |
US7610351B1 (en) | 2002-05-10 | 2009-10-27 | Oracle International Corporation | Method and mechanism for pipelined prefetching |
US6862674B2 (en) * | 2002-06-06 | 2005-03-01 | Sun Microsystems | Methods and apparatus for performing a memory management technique |
US7249352B2 (en) * | 2002-08-22 | 2007-07-24 | International Business Machines Corporation | Apparatus and method for removing elements from a linked list |
US20040040018A1 (en) * | 2002-08-22 | 2004-02-26 | Internatinal Business Machines Corporation | Apparatus and method for removing elements from a linked list |
US20050021576A1 (en) * | 2003-07-23 | 2005-01-27 | International Business Machines Corporation | Mostly concurrent garbage collection |
US7321908B2 (en) * | 2003-07-23 | 2008-01-22 | International Business Machines Corporational | Mostly concurrent garbage collection |
US7636745B1 (en) * | 2004-03-12 | 2009-12-22 | Sun Microsystems, Inc. | Concurrent-marking-initiation heuristic |
US20060031844A1 (en) * | 2004-06-04 | 2006-02-09 | David Dice | Techniques for accessing a shared resource using an improved synchronization mechanism |
US8046758B2 (en) | 2004-06-04 | 2011-10-25 | Oracle America, Inc. | Adaptive spin-then-block mutual exclusion in multi-threaded processing |
US7644409B2 (en) | 2004-06-04 | 2010-01-05 | Sun Microsystems, Inc. | Techniques for accessing a shared resource using an improved synchronization mechanism |
US7594234B1 (en) | 2004-06-04 | 2009-09-22 | Sun Microsystems, Inc. | Adaptive spin-then-block mutual exclusion in multi-threaded processing |
US20060026183A1 (en) * | 2004-07-27 | 2006-02-02 | Texas Instruments Incorporated | Method and system provide concurrent access to a software object |
US7475397B1 (en) | 2004-07-28 | 2009-01-06 | Sun Microsystems, Inc. | Methods and apparatus for providing a remote serialization guarantee |
US8452938B1 (en) | 2004-12-30 | 2013-05-28 | Azul Systems, Inc. | Garbage collection with memory quick release |
US8315912B2 (en) | 2005-12-23 | 2012-11-20 | Sharp Electronics Corporation | Integrated solar agent business model |
US7844499B2 (en) | 2005-12-23 | 2010-11-30 | Sharp Electronics Corporation | Integrated solar agent business model |
US20110047048A1 (en) * | 2005-12-23 | 2011-02-24 | Sharp Electronics Corporation | Integrated solar agent business model |
US10289728B2 (en) * | 2006-05-15 | 2019-05-14 | Avaya Inc. | Garbage collection of persistent objects with dynamic multikeys |
US7721068B2 (en) | 2006-06-12 | 2010-05-18 | Oracle America, Inc. | Relocation of active DMA pages |
US20080005495A1 (en) * | 2006-06-12 | 2008-01-03 | Lowe Eric E | Relocation of active DMA pages |
US7827374B2 (en) | 2006-06-12 | 2010-11-02 | Oracle America, Inc. | Relocating page tables |
US20070288718A1 (en) * | 2006-06-12 | 2007-12-13 | Udayakumar Cholleti | Relocating page tables |
US20070288719A1 (en) * | 2006-06-13 | 2007-12-13 | Udayakumar Cholleti | Approach for de-fragmenting physical memory by grouping kernel pages together based on large pages |
US7802070B2 (en) * | 2006-06-13 | 2010-09-21 | Oracle America, Inc. | Approach for de-fragmenting physical memory by grouping kernel pages together based on large pages |
US20080005521A1 (en) * | 2006-06-30 | 2008-01-03 | Udayakumar Cholleti | Kernel memory free algorithm |
US7500074B2 (en) | 2006-06-30 | 2009-03-03 | Sun Microsystems, Inc. | Identifying relocatable kernel mappings |
US20080005517A1 (en) * | 2006-06-30 | 2008-01-03 | Udayakumar Cholleti | Identifying relocatable kernel mappings |
US7472249B2 (en) | 2006-06-30 | 2008-12-30 | Sun Microsystems, Inc. | Kernel memory free algorithm |
US20080281885A1 (en) * | 2007-05-08 | 2008-11-13 | Microsoft Corporation | Interleaved garbage collections |
US7685182B2 (en) * | 2007-05-08 | 2010-03-23 | Microsoft Corporation | Interleaved garbage collections |
US20090112953A1 (en) * | 2007-10-30 | 2009-04-30 | Eric Lawrence Barsness | Enhanced garbage collection in a multi-node environment |
US8868623B2 (en) * | 2007-10-30 | 2014-10-21 | International Business Machines Corporation | Enhanced garbage collection in a multi-node environment |
US8612493B2 (en) * | 2008-10-30 | 2013-12-17 | International Business Machines Corporation | Allocation cache premarking for snap-shot-at-the-beginning concurrent mark-and-sweep collector |
US20100114997A1 (en) * | 2008-10-30 | 2010-05-06 | International Business Machines Corporation | Allocation cache premarking for snap-shot-at-the-beginning concurrent mark-and-sweep collector |
US20100153675A1 (en) * | 2008-12-12 | 2010-06-17 | Microsoft Corporation | Management of Native Memory Usage |
US8738877B2 (en) | 2011-12-14 | 2014-05-27 | Advance Micro Devices, Inc. | Processor with garbage-collection based classification of memory |
US20190146917A1 (en) * | 2013-06-22 | 2019-05-16 | Microsoft Technology Licensing, Llc | Log-structured storage for data access |
US11210220B2 (en) * | 2013-06-22 | 2021-12-28 | Microsoft Technology Licensing, Llc | Log-structured storage for data access |
US12019541B2 (en) * | 2022-10-17 | 2024-06-25 | Oracle International Corporation | Lazy compaction in garbage collection |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6052699A (en) | Garbage collection without fine-grain synchronization | |
US6289360B1 (en) | Method and system for eliminating synchronization between sweep and allocate in a concurrent garbage collector | |
Baker | The Treadmill: Real-time garbage collection without motion sickness | |
US6321240B1 (en) | Data structure partitioning with garbage collection to optimize cache utilization | |
US6330556B1 (en) | Data structure partitioning to optimize cache utilization | |
Doligez et al. | A concurrent, generational garbage collector for a multithreaded implementation of ML | |
EP0881576B1 (en) | Method and apparatus for generational garbage collection in a shared heap memory by means of multiple processor units | |
Appel et al. | Real-time concurrent collection on stock multiprocessors | |
US5321834A (en) | Method and system for reclaiming unreferenced computer memory space | |
US6539464B1 (en) | Memory allocator for multithread environment | |
US6826583B1 (en) | Local allocation buffers for parallel garbage collection | |
US6249793B1 (en) | Mostly concurrent compaction in a garbage collection system | |
US6105040A (en) | Method and apparatus for managing stored objects | |
US5313647A (en) | Digital data processor with improved checkpointing and forking | |
US5088036A (en) | Real time, concurrent garbage collection system and method | |
EP0173464A2 (en) | Computer memory system with parallel garbage collection independent from an associated user processor | |
Hudson et al. | Sapphire: Copying GC without stopping the world | |
Brownbridge | Cyclic reference counting for combinator machines | |
Huelsbergen et al. | Very concurrent mark-&-sweep garbage collection without fine-grain synchronization | |
Detlefs | Concurrent garbage collection for C++ | |
US20040186863A1 (en) | Elision of write barriers for stores whose values are in close proximity | |
Vaughan et al. | Supporting large persistent stores using conventional hardware | |
Ram et al. | Parallel garbage collection without synchronization overhead | |
Dietz et al. | CRegs: a new kind of memory for referencing arrays and pointers. | |
EP0430668B1 (en) | Method and system for reclaiming unreferenced computer memory space |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: LUCENT TECHNOLOGIES INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HUELSBERGEN, LORENZ FRANCIS;WINTERBOTTOM, PHILIP STEVEN;REEL/FRAME:008897/0215 Effective date: 19971209 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: THE CHASE MANHATTAN BANK, AS COLLATERAL AGENT, TEX Free format text: CONDITIONAL ASSIGNMENT OF AND SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:LUCENT TECHNOLOGIES INC. (DE CORPORATION);REEL/FRAME:011722/0048 Effective date: 20010222 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
AS | Assignment |
Owner name: LUCENT TECHNOLOGIES INC., NEW JERSEY Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:JPMORGAN CHASE BANK, N.A. (FORMERLY KNOWN AS THE CHASE MANHATTAN BANK), AS ADMINISTRATIVE AGENT;REEL/FRAME:018590/0047 Effective date: 20061130 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
FPAY | Fee payment |
Year of fee payment: 12 |
|
AS | Assignment |
Owner name: CREDIT SUISSE AG, NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:ALCATEL-LUCENT USA INC.;REEL/FRAME:030510/0627 Effective date: 20130130 |
|
AS | Assignment |
Owner name: ALCATEL-LUCENT USA INC., NEW JERSEY Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:033950/0001 Effective date: 20140819 |
|
AS | Assignment |
Owner name: OMEGA CREDIT OPPORTUNITIES MASTER FUND, LP, NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:WSOU INVESTMENTS, LLC;REEL/FRAME:043966/0574 Effective date: 20170822 Owner name: OMEGA CREDIT OPPORTUNITIES MASTER FUND, LP, NEW YO Free format text: SECURITY INTEREST;ASSIGNOR:WSOU INVESTMENTS, LLC;REEL/FRAME:043966/0574 Effective date: 20170822 |
|
AS | Assignment |
Owner name: WSOU INVESTMENTS, LLC, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ALCATEL LUCENT;REEL/FRAME:044000/0053 Effective date: 20170722 |
|
AS | Assignment |
Owner name: WSOU INVESTMENTS, LLC, CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:OCO OPPORTUNITIES MASTER FUND, L.P. (F/K/A OMEGA CREDIT OPPORTUNITIES MASTER FUND LP;REEL/FRAME:049246/0405 Effective date: 20190516 |
|
AS | Assignment |
Owner name: OT WSOU TERRIER HOLDINGS, LLC, CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:WSOU INVESTMENTS, LLC;REEL/FRAME:056990/0081 Effective date: 20210528 |