EP0881576B1 - Procédé et dispositif de récupération des locations inutilisées d'une mémoire tas partagée utilisants plusieurs unités de traitement - Google Patents

Procédé et dispositif de récupération des locations inutilisées d'une mémoire tas partagée utilisants plusieurs unités de traitement Download PDF

Info

Publication number
EP0881576B1
EP0881576B1 EP98201604A EP98201604A EP0881576B1 EP 0881576 B1 EP0881576 B1 EP 0881576B1 EP 98201604 A EP98201604 A EP 98201604A EP 98201604 A EP98201604 A EP 98201604A EP 0881576 B1 EP0881576 B1 EP 0881576B1
Authority
EP
European Patent Office
Prior art keywords
processing units
garbage collection
computer
mutation
shared heap
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
Application number
EP98201604A
Other languages
German (de)
English (en)
Other versions
EP0881576A1 (fr
Inventor
David M. Ungar
Mario I. Wolczko
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems 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 Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of EP0881576A1 publication Critical patent/EP0881576A1/fr
Application granted granted Critical
Publication of EP0881576B1 publication Critical patent/EP0881576B1/fr
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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
    • G06F12/0276—Generational garbage collection
    • 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/99941—Database schema or data structure
    • Y10S707/99944—Object-oriented database structure
    • Y10S707/99945—Object-oriented database structure processing
    • 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

  • This invention relates to the field of computer memory allocation and deallocation. Specifically, this invention is a new and useful method, apparatus, system, and computer program product for using generational garbage collection techniques to automatically reclaim garbage nodes from a heap memory shared by a plurality of processing units.
  • Memory allocation and deallocation techniques have become very important in structured programming and object oriented programming methodologies.
  • Memory allocated from a heap can be used to store information. Often this information is an instantiated object within an object-oriented paradigm.
  • An allocated portion of heap memory is a node.
  • the subsequently described techniques apply to both nodes that contain data and nodes that are instantiated objects. These nodes are explicitly allocated by a program.
  • many modern systems use heap-memory garbage collection techniques to recover previously allocated nodes that are no longer used.
  • modern computers often have multiple processing units that can access a shared heap memory, with each processing unit allocating nodes in the shared heap (thus mutating the shared heap) and each processing unit being capable of performing garbage collection on the shared heap.
  • Computer memory is a resource. Programs cause a computer to perform operations (to execute) based on instructions stored in memory. Executing programs also use memory to store information. This information is often organized into memory resident data structures. These data structures are often linked together by pointers from one structure to another and are often referenced through pointers in static, register and stack variable storage.
  • Executing programs often need memory for a purpose that extends for a limited period of time. For example, a program may allocate memory to hold information, store the information into the allocated memory, operate on the stored information to produce a result, and then have no further need of the stored information. Once the program no longer needs the stored information, the allocated memory can be released for later reuse.
  • Static allocation binds variables to storage locations at compile and/or link time.
  • Stack allocation pushes an activation frame on the processing unit's stack when a program block prepares to execute. This activation frame contains storage for variables within the scope of execution for the program block executing in the processing unit. Once the program block completes, the activation frame is popped from stack. Variables stored in the activation frame are not saved from one activation of the block to the next.
  • Heap allocation allows memory for variables to be allocated and deallocated in any order and these variables can outlive the procedure (or block) that created them. Once memory is deallocated it is available for reallocation for another use.
  • a "node” is an area of memory allocated from a heap. Nodes are accessed through pointers.
  • a direct (or simple) pointer is the node's address in the heap.
  • An indirect pointer (sometimes called a "handle") points to an address in memory that contains the address of the node. More complex pointers exist. Indirect pointers allow nodes to be moved in the heap without needing to update the occurrences of the handle.
  • the "root set” is a set of node references such that the referenced nodes must be retained regardless of the state of the heap.
  • a node is reachable if the node is in the root set, or referenced by a reachable node.
  • the "reference set” is the set of node references contained in a node.
  • a memory leak occurs when a node becomes unreachable from the root set and is never reclaimed.
  • a memory leak reduces the amount of heap memory available to the program.
  • a garbage node is a node that becomes unreachable from the root set and can be reclaimed.
  • Heap memory can be used by invoking explicit node allocation and deallocation procedures.
  • a programmer knows when a new node is required, it is often difficult for the programmer to know when a node is no longer reachable.
  • problems may occur when programmers explicitly deallocate nodes.
  • One of these problems is that it is very difficult to debug memory leaks.
  • the design of the application being programmed obfuscates when the programmer can explicitly deallocate memory.
  • it when one portion of a program is ready to deallocate memory, it must be certain that no other portion of the program will use that memory.
  • OOP object oriented programming
  • a mutator program changes (mutates) the connectivity of the graph of live nodes in the heap.
  • mutation includes any activity that accesses the nodes in the heap for purposes other than garbage collection.
  • nodes are allocated from the heap as memory is needed by the mutator program. These nodes are not initially reclaimed when they are no longer needed. Instead, when a memory allocation attempt fails or in response to some condition (for example, on expiration of a clock or counter), the garbage collection process is automatically invoked and unused memory allocated to garbage nodes is reclaimed for subsequent reuse.
  • Some garbage collection methods copy (or scavenge) nodes (that is, these methods relocate nodes that appear to be alive from one location in the heap to another location). These methods require a mechanism that allows existing pointers to the original location of the node to be used to access the relocated node. These mechanisms include (among others) updating existing pointers to the node's original location and providing indirect pointers to the new location of the node.
  • Generational garbage collection algorithms separate nodes into two or more areas in the heap depending on the node's age. Each area is a generation. Nodes are first allocated from the creation area within the youngest generation and are copied to the older generation if the node survives long enough ("long enough" is often until a subsequent scavenge operation). These garbage collection algorithms concentrate on reclaiming storage from the youngest generation area where most of the garbage is found. Generally, the number of live nodes in the youngest generation is significantly less than the number of live nodes in the other generation areas so that the time required to scavenge nodes in the youngest generation is less than the time required to scavenge the other generation areas.
  • a scavenge operation of the newer generation is termed a minor collection. Any garbage collection operation on an older generation area is termed a major collection. The minor collection operation occurs more frequently than the major collection operation because of the reduced overhead and higher efficiency of the minor collection process.
  • any pointers to the copied node must be updated or tracked so that future references to the copied node eventually succeed. Further, pointers to nodes in the younger generation contained in copied nodes must be accessed to determine the reference set.
  • FIG. 1a illustrates a shared heap area indicated by general reference character 100.
  • the shared heap area 100 includes a generational garbage collection area 101.
  • the generational garbage collection area 101 includes a younger generation 103 and an older generation area 105 .
  • the younger generation 103 is subdivided into a creation area 107 , a 'to' area 109 , and a 'from' area 111.
  • Nodes (such as a new node 113) are first created in the creation area 107.
  • live nodes in the creation area 107 ⁇ such as the new node 113 ⁇ along with live nodes in the 'from' area 111 , are copied to the 'to' area 109 (thus emptying the creation area 107) and the meaning of the 'to' area 109 and the 'from' area 111 are interchanged.
  • live nodes in the younger generation 103 are copied to the older generation area 105 as determined by the implementation of the garbage collection process. This results in a promoted node 115 in the older generation area 105.
  • the creation area 107 contains the youngest nodes.
  • a card-marked heap, indicated by general reference character, 120 includes a card-marked region of heap memory 121 .
  • the card-marked region of heap memory 121 contains a first card 123 and a last card 125 .
  • a plurality of nodes 127 are distributed throughout the card-marked region of heap memory 121.
  • the first card 123 is associated with a first card marker 129 and the last card 125 is associated with a second card marker 131 . Both the first card marker 129 and the second card marker 131 are contained in a card mark vector 133. When memory is modified in one of the cards 123, 125 , the appropriate card marker is flagged. Thus, in the illustration of Figure 1b, a write operation was performed within the first card 123 subsequent to the last scavenge of the card-marked region of heap memory 121 . This write operation marked the first card marker 129 as 'dirty' as indicated by the 'X' in the first card marker 129 .
  • a single processor 135 controls mutation and garbage collection of the card-marked region of heap memory 121 .
  • Code within the mutator program marks the cards in the card mark vector 133 as the program executes.
  • the garbage collection process examines the marked cards for changed or new pointers.
  • This paper describes how generational garbage collectors need to keep track of references from older to younger generations so that younger generations can be garbage collected without inspecting every object in the older generation(s).
  • the set of locations potentially containing pointers to newer objects is often called the remember set.
  • the system must ensure that the updated location is added to the remembered set if the store creates a reference from an older to a newer object.
  • This mechanism is usually referred to as a write barrier or store check.
  • the compiler can know statically that no store check is necessary, for example, when storing an integer (assuming that integers are implemented as immediates rather than as real heap-allocated objects).
  • a store check must be executed for every store operation. Since stores are fairly frequent in non-functional languages, an efficient write barrier implementation is essential. The write barrier implementation described reduces the write barrier overhead in the mutator to only two extra instructions per checked store.
  • FIG. 1c A prior art heap allocation process is illustrated in Figure 1c .
  • a 'heap allocation' process indicated by general reference character 150 , initiates at a 'start' terminal 151 and continues to a 'node allocation' procedure 153 that attempts to allocate a node from the heap.
  • An 'insufficient heap' decision procedure 155 determines whether or not the 'node allocation' procedure 153 successfully allocated the node.
  • the 'heap allocation' process 150 completes through an 'end' terminal 157 if the 'node allocation' procedure 153 was successful (meaning that the node was allocated from the creation area of the heap) as determined by the 'insufficient heap' decision procedure 155 .
  • the 'heap allocation' process 150 continues to a 'garbage collection' procedure 159 if the 'node allocation' procedure 153 was unsuccessful.
  • the 'garbage collection' procedure 159 performs garbage collection processes to generate free space in the heap. It does this by first stopping mutation of the heap and then scavenging (copying) all living nodes from one area of the heap to another while updating references (pointers) to point to the new copy of the node instead of the original node.
  • the 'heap allocation' process 150 again attempts to allocate the node at the 'node allocation' procedure 153 and if successful the 'heap allocation' process 150 completes through the 'end' terminal 157 .
  • the heap is filled with accessible nodes such that the 'garbage collection' procedure 159 is unable to free enough space to allocated the requested node that other procedures (not shown) are required to handle the heap-full condition.
  • Figure 1d illustrates a prior art uniprocessor garbage collection process 170 used to scavenge live nodes.
  • the uniprocessor garbage collection process 170 initiates at a 'start' terminal 171 and continues to a 'locate pointer' procedure 173 that locates a pointer from the mutator's stack, static variables, and heap.
  • the uniprocessor garbage collection process 170 continues to a 'scavenge live node' procedure 175 that scavenges the live node referenced by the pointer.
  • the uniprocessor garbage collection process 170 repeats the 'locate pointer' procedure 173 and the 'scavenge live node' procedure 175 until all the pointers have been processed.
  • the uniprocessor garbage collection process 170 continues to a 'search copied nodes for pointer to new' procedure 177 that searches the nodes that were copied during the 'scavenge live node' procedure 175 to locate pointers in the copied nodes that reference new nodes.
  • the uniprocessor garbage collection process 170 completes through an 'end' terminal 179 after all copied nodes have been searched.
  • the uniprocessor garbage collection process 170 continues to a 'node already copied' decision procedure 181 that determines whether the node has been copied. If the node has not been copied, the uniprocessor garbage collection process 170 continues to a 'copy node' procedure 183 that copies the node.
  • the uniprocessor garbage collection process 170 then continues to an 'update pointer' procedure 185 that updates the pointer to new.
  • the uniprocessor garbage collection process 170 then repeats through the 'search copied nodes for pointer to new' procedure 177 until all copied nodes have been searched.
  • a read-barrier can also be implemented using memory access control facilities. These memory access control facilities can be configured to detect an attempted access within a range of memory locations and to post an exception when such an access occurs. This approach removes the overhead for each read operation but at the expense of manipulating memory page tables and of occasional exception processing. In addition, some computers do not have such a memory capability.
  • KAZUHIRO OGATA ('The design and implementation of home' acm sigplan notices, vol. 27, no. 7, 1 July 1992, pages 44-54) describes HoME, a version of Smalltalk, which can be efficiently executed on a multiprocessor and can be executed in parallel by combining a Small talk process with a Mach thread and executing the process on the thread.
  • HoME is nearly the same as ordinary Smalltalk except that multiple processes may execute in parallel. Thus, almost all applications running on ordinary Smalltalk can be executed on HoME without changed in their code.
  • HoME was designed and implemented based on the following fundamental policies: (1) theoretically, an infinite number of processes can become active; (2) the moment a process is scheduled, it becomes active; (3) no process switching occurs; (4) HoME is equivalent to ordinary Smalltalk except for the previous three policies.
  • the paper illustrates the performance of an implementation of HoME running on a computer which had four processors.
  • AKIRA IMAI ET AL ('Evaluation of parallel copying garbage collection on a shared- memory multiprocessor' ieee transactions on parallel and distribution systems, vol. 4, no. 9,1 September 1993, pages 1030-1040) describes a parallel copying garbage collection algorithm for symbolic languages executing on shared-memory multiprocessors is proposed.
  • the algorithm is an extension of Baker's sequential algorithm with a novel method of heap allocation to prevent fragmentation and facilitate load distribution during garbage collection.
  • An implementation of the algorithm within a concurrent logic programming system, VPIM has been evaluated and the results, for a wide selection of benchmarks, are analyzed here. It demonstrates how much the algorithm reduces the contention for critical sections during garbage collection, 2) how well the load balancing strategy works and its expected overheads, and 3) the expected speedup achieved by the algorithm.
  • the present invention provides an economical, apparatus, method, system and computer program product for providing enhanced operation of garbage collection programs in a multiprocessor environment as defined by the independent claims.
  • the apparatus has a plurality of processing units coupled to a shared heap memory.
  • the shared heap memory is accessible by the plurality of processing units.
  • the apparatus includes a first detection mechanism that is configured to detect an initiate garbage collection condition by one of the plurality of processing units.
  • the apparatus also includes a mutation suspension mechanism that is responsive to the first detection mechanism.
  • the mutation suspension mechanism is configured to pause mutation of the shared heap memory by the plurality of processing units.
  • the apparatus includes an initiation mechanism that is configured to initiate a generational garbage collection process in the plurality of processing units after the plurality of processing units pause mutation of the shared heap memory in response to the mutation suspension mechanism.
  • the apparatus also includes a second detection mechanism that is configured to detect completion of the generational garbage collection process in the plurality of processing units. These generational garbage collection processes initiated by the initiation mechanism.
  • the apparatus also includes a resumption mechanism that is configured to resume mutation of the shared heap memory by the plurality of processing units. This resumption mechanism is responsive to the second detection mechanism.
  • Another aspect of the invention is a system having a computer that includes a plurality of processing units coupled to a shared heap memory.
  • the shared heap memory is accessible by the plurality of processing units.
  • the system includes a first detection mechanism that is configured to detect an initiate garbage collection condition by one of the plurality of processing units.
  • the system also includes a mutation suspension mechanism that is responsive to the thirst detection mechanism.
  • the mutation suspension mechanism is configured to pause mutation of the shared heap memory by the plurality of processing units.
  • the system includes an initiation mechanism that is configured to initiate a generational garbage collection process in the plurality of processing units after the plurality of processing units pause mutation of the shared heap memory in response to the mutation suspension mechanism.
  • the system also includes a second detection mechanism that is configured to detect completion of the generational garbage collection process in the plurality of processing units. These generational garbage collection processes initiated by the initiation mechanism.
  • the system also includes a resumption mechanism that is configured to resume mutation of the shared heap memory by the plurality of processing units. This resumption mechanism is responsive to the second detection mechanism.
  • Yet a further aspect of the invention is a computer program product embedded on a computer usable medium for causing a computer, having a plurality of processing units coupled to a shared heap memory, to mutate and garbage-collect the shared memory.
  • the computer readable code When executed on a computer, the computer readable code causes a computer to effect a first detection mechanism, a mutation suspension mechanism, an initiation mechanism, a second detection mechanism, and a resumption mechanism.
  • a first detection mechanism a mutation suspension mechanism
  • an initiation mechanism initiation mechanism
  • a second detection mechanism and a resumption mechanism.
  • Node ⁇ An area of memory allocated from the heap.
  • An instantiated object resides in a node. It generally contains instance variables and a pointer to a class that references the object's methods.
  • Pointer ⁇ A value used as an address to a node. By locating pointers to nodes a garbage collection algorithm determines which nodes are live.
  • Procedure ⁇ A self-consistent sequence of steps leading to a desired result. These steps are those requiring physical manipulation of physical quantities. Usually these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. These signals are referred to as bits, values, elements, symbols, characters, terms, numbers, or the like. It will be understood by those skilled in the art that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.
  • the manipulations performed by a computer in executing computer instructions are often referred to in terms, such as adding or comparing, that are commonly associated with mental operations performed by a human operator. In the present invention no such capability of a human operator is necessary in any of the operations described herein.
  • the operations are machine operations. Useful machines for performing the operations of the invention include programmed general purpose digital computers or similar devices. In all cases the method of computation is distinguished from the method of operation in operating a computer.
  • the present invention relates to method steps for operating a computer in processing electrical or other (e.g., mechanical, chemical) physical signals to generate other desired physical signals.
  • the invention also relates to apparatus for performing these operations.
  • This apparatus may be specially constructed for the required purposes or it may comprise a general purpose computer as selectively activated or reconfigured by a computer program stored in the memory of a computer.
  • the procedures presented herein are not inherently related to a particular computer or other apparatus.
  • various general purpose machines may be used with programs written in accordance with the teachings herein, or it may prove more convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these machines will appear from the following description.
  • the invention may be embodied in a computer readable storage medium encoded with a program that causes a computer to perform the programmed logic.
  • FIG. 2 Some of the elements of a multiprocessor computer, as indicated by general reference character 200, configured to support the invention are shown in Figure 2 wherein a central processor unit (CPU) 201 is shown, having at least two processing units 203 (such as a first CPU 205 and a second CPU 207), a shared heap memory 209 and an input/output (I/O) section 211.
  • the input/output (I/O) section 211 is connected to a disk storage unit 213 and a CD-ROM drive unit 215.
  • the CD-ROM drive unit 215 can read a CD-ROM medium 217 that typically contains a program and data 219 .
  • a user control device 221 provides a user with controlling access to the multiprocessor computer 200 either directly, through a network, or through some other equivalent means.
  • the CD-ROM drive unit 215 , along with the CD-ROM medium 217 , and the disk storage unit 213 comprise a filestorage mechanism.
  • Such a computer system is capable of executing applications that embody
  • Figure 3 illustrates a node in heap memory as indicated by general reference character 300 including a node header 301 containing a 'node lock' field 303 and a 'garbage collection status' field 304 .
  • the node header 301 includes node specific information and possibly other heap management information.
  • the 'node lock' field 303 contains information that allows one skilled in the art to lock the node as to the other processing units.
  • the 'garbage collection status' field 304 contains information specific to the generational garbage collection process. This information includes whether the node has been promoted.
  • the node 300 also includes a 'node storage' area 305 that is used by the mutator to store mutator-specific information.
  • Figure 4a illustrates a 'node allocation' process, indicated by general reference character 400, that initiates at a 'start' terminal 401 and continues to a 'node allocation' procedure 403.
  • the 'node allocation' procedure 403 executes in one of the processing units and allocates a node from the shared heap memory 209 .
  • the 'node allocation' process 400 continues to a 'threshold exceeded' decision procedure 405 that determines whether the 'node allocation' procedure 403 reduced the amount of shared memory available for future allocation below a threshold. That is, whether the 'node allocation' procedure 403 generated a limited heap memory condition.
  • the 'node allocation' process 400 completes through an 'end' terminal 407 . However if the threshold was reached, the 'node allocation' process 400 continues to a 'pause mutation' procedure 408 that pauses execution of code in the processing unit that can mutate the shared heap memory 209.
  • a 'pause mutation' procedure 408 that pauses execution of code in the processing unit that can mutate the shared heap memory 209.
  • an 'initiate garbage collection synchronization' procedure 410 signals a synchronization process with the processing units. Then, the 'node allocation' process 400 continues to a 'wait for mutation pause' procedure 411 that monitors the other processing units that can mutate the shared heap memory 209. The 'wait for mutation pause' procedure 411 waits until these processing units signal that they have paused their mutating processes. Once all the processing units have paused the mutating processes, the 'node allocation' process 400 advances to a 'collect garbage' procedure 413 that performs the generational garbage collection process in the shared heap memory 209 as is subsequently described.
  • the 'node allocation' process 400 advances to an 'indicate garbage collection phase complete' procedure 415 that signals the other processing units that this processing unit has completed its garbage collection processing.
  • the 'node allocation' process 400 continues at a 'wait for other processing units to complete garbage collection' procedure 417 that monitors the state of the other processing units to detect when all processing units have completed garbage collection. Mutation is resumed at a 'resume mutation' procedure 419 after all processing units that can garbage collect the shared heap memory 209 indicate that their garbage collection process is complete.
  • the 'node allocation' process 400 completes through the 'end' terminal 407 .
  • Figure 4b illustrates a 'detect garbage collection phase' process indicated by general reference character 450 that initiates at a 'start' terminal 451 and continues to a 'garbage collection synchronization initiated' decision procedure 453 .
  • the 'detect garbage collection phase' process 450 is invoked in each processing unit when the processing unit executes a call instruction, a backwards branch instruction, or is ready to return from a runtime support routine.
  • the 'garbage collection synchronization initiated' decision procedure 453 determines whether the signal to stop mutation (such as set by the 'initiate garbage collection synchronization' procedure 410 ) has been raised.
  • the 'detect garbage collection phase' process 450 completes through an 'end' terminal 455 . However, if the signal has been raised, the 'detect garbage collection phase' process 450 continues to a 'pause mutation' procedure 457 that inhibits all processes executing in the processing unit from mutating the shared heap memory 209. Generally this is accomplished by suspending those threads or processes that access the shared heap memory 209 . After these processes are inhibited from mutating the shared heap memory 209, the 'detect garbage collection phase' process 450 continues to an 'indicate mutation paused' procedure 459 . The 'indicate mutation paused' procedure 459 signals that this processing unit has paused mutation.
  • a 'wait until other processing units pause mutation' procedure 461 monitors the signals of the other processing units to determine when the other processing units have paused mutation.
  • one or more of the processing units can continue to a 'collect garbage' procedure 463.
  • the 'collect garbage' procedure 463 is a modified generational garbage collection process as is subsequently described. After the 'collect garbage' procedure 463 finishes the 'detect garbage collection phase' process 450 continues to an 'indicate garbage collection phase complete' procedure 465 that raises a signal that this processing unit has completed the 'collect garbage' procedure 463.
  • the processing unit then waits at a 'wait for other processing units to complete garbage collection' procedure 467 until it detects that the other processing units have also signaled that they have completed garbage collection. Once the other processing units signal completion of their garbage collection process, a 'resume mutation' procedure 469 in each processing unit resumes mutation of the shared heap memory 209 by the processes inhibited by the 'pause mutation' procedure 457. Finally, the 'detect garbage collection phase' process 450 completes through the 'end' terminal 455.
  • Figure 5 illustrates an event timeline indicated by general reference character 500 that shows the sequence of the processes previously described for Figure 4a and Figure 4b.
  • An arrow-of-time 501 indicates the direction of increasing time.
  • Lines below a mutation event line 503 indicate that processing units are able to perform mutation.
  • Lines above a garbage collection event line 505 indicate that processing units are able to perform generational garbage collection.
  • the event timeline 500 shows the events related to the invention assuming the use of four parallel processing units each represented by an event line: a first processing unit event line 507 represents the mutation and generational garbage collection operations of a first processing unit; a second processing unit event line 509 represents the mutation and generational garbage collection operations of a second processing unit; a third processing unit event line 511 and a fourth processing unit event line 513 represent respective mutation and generational garbage collection operations. These lines 507, 509, 511, 513 are primed and double primed to indicate different processing states in the same processing unit. When a processing unit is capable of mutating the shared heap memory 209 , its respective line is horizontal and below the mutation event line 503 .
  • a multiprocessor event line 515 indicates when the multiprocessor is capable or mutating the shared heap memory 209 or when the multiprocessor is garbage collecting the shared heap memory 209 .
  • the processing units representing these lines 507, 509, 511, 513 are all capable of mutating the shared heap memory 209 .
  • the multiprocessor event line 515 is on the mutation event line 503 .
  • a mutator in the processing unit represented by the first processing unit event line 507 attempts to allocate a node from the heap and determines that the free space in creation area of the heap is below a threshold value in accordance with the process previously described for Figure 4a. Then, the first processing unit suspends mutation, raises a garbage collect indicator and waits for the other processing units to also pause mutation. At this point the line representing the first processing unit starts to slant towards a 'mutation suspension synchronization' event 517 . As the other processing units detect the garbage collect indicator asserted by the first processing unit, they also suspend mutation and raise their own garbage collect indicator.
  • the last processing unit (represented by the fourth processing unit event line 513) suspends mutation and the convergence of these lines 507, 509, 511, 513 at the 'mutation suspension synchronization' event 517 indicate that the processing units are synchronized and that the shared heap memory 209 is no longer subject to mutation.
  • the multiprocessor generational garbage collection process is greatly simplified because the shared heap memory 209 is no longer subject to mutation.
  • each processing unit 507 ', 509', 511', 513' starts to garbage collect the shared heap memory 209 as is subsequently described.
  • each processing unit 507', 509', 511', 513' completes its generational garbage collection process it waits for the other processing units to complete. This condition is satisfied at a 'garbage collection complete synchronization' event 519 .
  • the multiprocessor event line 515 transitions from the garbage collection event line 505 to the mutation event line 503 and each processing unit resumes mutation operations as indicated by the double primed event lines 507", 509", 511", 513 ".
  • the processing units initiate generational garbage collecting, they must not interfere with each other when processing nodes in the shared heap memory 209 .
  • the garbage collection process generates a root set of pointers from the processor's stack, static variables, and the heap.
  • each processing unit locates pointers in its own local static and stack variables.
  • the process of scanning the shared heap memory 209 for pointers can be shared between the processing units.
  • Figure 6a illustrates a card-marked shared heap memory indicated by general reference character 600 .
  • the card-marked shared heap memory 600 is similar to the card-marked heap 120 shown in Figure 1b and includes a card-marked region of shared heap memory 601 , a first card 603 , a last card 605 , a plurality of nodes 607 , a first card marker 609 , and a second card marker 611 .
  • the first card marker 609 and the second card marker 611 are included in a card mark vector 613 .
  • the card-marked shared heap memory 600 is separated into four partitions: a first processor partition 615, a second processor partition 617, a third processor partition 619 and a fourth processor partition 621 .
  • the corresponding processing unit for each partition 615, 617, 619, 621 scans its partition in the card mark vector 613 to locate and process modified pointers in the corresponding portion of the card-marked region of shared heap memory 601 .
  • Figure 6a indicates that the first card marker 609 is marked.
  • the first processing unit scans the first processor partition 615 of the card mark vector 613 the first processing unit will scan the first card 603 to locate pointers.
  • Each of the other processing units also scan their portion of the card mark vector 613. Because no other cards are marked, these processing units will not need to scan their respective portions of the card-marked region of shared heap memory 601 .
  • FIG. 6b illustrates a multiprocessor generational garbage collection process indicated by general reference character 650 .
  • Each processing unit performs the multiprocessor generational garbage collection process 650 when invoked from either the 'collect garbage' procedure 413 or the 'collect garbage' procedure 463 .
  • the multiprocessor generational garbage collection process 650 initiates at a 'start' terminal 651 and continues to a 'locate pointer assigned to processing unit' procedure 653 .
  • the 'locate pointer assigned to processing unit' procedure 653 examines the mutator's stack, variables and heap, as determined from the portion of the card mark vector 613 assigned to the processing unit executing the multiprocessor generational garbage collection process 650 , for pointers.
  • the multiprocessor generational garbage collection process 650 continues to a 'scavenge live node' procedure 655 that scavenges the live nodes found from the 'locate pointer assigned to processing unit' procedure 653 .
  • the multiprocessor generational garbage collection process 650 repeats the 'locate pointer assigned to processing unit' procedure 653 and the 'scavenge live node' procedure 655 until these pointers have been processed.
  • the multiprocessor generational garbage collection process 650 continues to a 'search copied nodes for pointer to new' procedure 657 to locate pointers in the copied nodes that reference new nodes.
  • the multiprocessor generational garbage collection process 650 completes through an 'end' terminal 659 after all copied nodes have been searched.
  • the multiprocessor generational garbage collection process 650 continues to a 'node already copied' decision procedure 661 that determines whether the node has been copied. If the node has not been copied, the multiprocessor generational garbage collection process 650 continues to a 'copy node' procedure 663 that copies the node. Regardless of the decision at the 'node already copied' decision procedure 661 the multiprocessor generational garbage collection process 650 then continues to an 'update pointer' procedure 665 that updates the pointer to new. The multiprocessor generational garbage collection process 650 then repeats through the 'search copied nodes for pointer to new' procedure 657 until all copied nodes have been searched.
  • Figure 6c illustrates a multiprocessor garbage collection process indicated by general reference character 670 .
  • the multiprocessor garbage collection process 670 is invoked by the 'search copied nodes for pointer to new' procedure 657 and initiates at a 'start' terminal 671.
  • the multiprocessor garbage collection process 670 then continues to an 'advance to first node' procedure 673 that locates the first node in the shared heap memory 209 that the processing unit will garbage collect.
  • an 'atomic test and lock' procedure 675 attempts to lock the node using techniques well understood by one skilled in the art. Each node in the new generation must be locked before scavenging the node.
  • a 'node locked by other' decision procedure 677 continues to a 'node still locked' decision procedure 678 if the node is locked by another processing unit.
  • the 'node still locked' decision procedure 678 repeats until the node becomes unlocked. If the node is not locked by another processing unit, the 'atomic test and lock' procedure 675 succeeds and locks the node for use by this processing unit so that the 'node locked by other' decision procedure 677 is not satisfied.
  • the multiprocessor garbage collection process 670 then advances to a 'node previously scavenged' decision procedure 679 that checks the 'garbage collection status' field 304 of the node to determine whether the node has already been scavenged by another processing unit.
  • the multiprocessor garbage collection process 670 continues to a 'scavenge node' procedure 680 if the node has not been previously scavenged.
  • the 'scavenge node' procedure 680 then performs the scavenge operation on the node as is understood by those skilled in the art.
  • the multiprocessor garbage collection process 670 continues to an 'update pointer' procedure 681 that updates the pointer. Additionally, when the node is no longer locked by another at the 'node still locked' decision procedure 678 or after the node is scavenged by the 'scavenge node' procedure 680 , the multiprocessor garbage collection process 670 continues to the 'update pointer' procedure 681 .
  • the multiprocessor garbage collection process 670 continues to an 'unlock node' procedure 682 that unlocks the node, if it is locked, so that other processing units can operate on it if required.
  • the multiprocessor garbage collection process 670 continues to an 'advance to next node' procedure 683 that locates the next node in the shared heap memory 209 that this processing unit needs to scavenge.
  • a 'node found' decision procedure 685 determines whether the 'advance to next node' procedure 683 located another node for this processing unit to scavenge.
  • the multiprocessor garbage collection process 670 loops back to the 'atomic test and lock' procedure 675 for continued processing. Otherwise, the multiprocessor garbage collection process 670 completes through an 'end' terminal 687 .

Claims (13)

  1. Procédé contrôlé par un ordinateur pour regrouper les places en mémoire d'une mémoire tas partagée (209) soumise à une mutation par au moins deux unités de traitement (205, 207), le procédé comprenant les étapes consistant à :
    (a) détecter (405, 453) une condition de lancement de regroupement de places en mémoire par l'une desdites au moins deux unités de traitement ;
    (b) mettre en attente (408, 457) la mutation de ladite mémoire tas partagée par lesdites'au moins deux unités de traitement ;
    (c) lancer un traitement de regroupement de places en mémoire à générations (413, 463) sur ladite mémoire tas partagée ;
    (d) détecter (415, 465) l'achèvement dudit traitement de regroupement de places en mémoire à générations ; et
    (e) reprendre (419, 469) la mutation de ladite mémoire tas partagée par lesdites au moins deux unités de traitement ;
       caractérisé en ce que les étapes (c) et (d) sont exécutées dans lesdites au moins deux unités de traitement, ladite mémoire tas partagée (209) est une mémoire tas partagée à marquage de cartes (600), et le procédé comprend, de plus :
    (f) le partitionnement de ladite mémoire tas partagée à marquage de cartes en une pluralité de partitions (615, 617, 619, 621) ; et
    (g) l'attribution de l'une desdites au moins deux unités de traitement à l'une de ladite pluralité des partitions.
  2. Procédé contrôlé par un ordinateur selon la revendication 1, dans lequel l'étape (b) comprend les étapes consistant à :
    (b1) signaler (408, 457) auxdites au moins deux unités de traitement de mettre en attente la mutation de ladite mémoire tas partagée ; et
    (b2) attendre (411, 461) que lesdites au moins deux unités de traitement mettent en attente la mutation de ladite mémoire tas partagée.
  3. Procédé contrôlé par un ordinateur selon la revendication 1, dans lequel l'étape (d) comprend les étapes consistant à :
    (d1) signaler (415, 465), par lesdites au moins deux unités de traitement, que ledit traitement de regroupement de places en mémoire à générations est achevé ; et
    (d2) attendre (417, 467) que ledit traitement de regroupement de places en mémoire à générations s'achève dans lesdites au moins deux unités de traitement.
  4. Procédé contrôlé par un ordinateur selon l'une quelconque des revendications 1 à 3, dans lequel l'étape (c) comprend, de plus, les étapes consistant à :
    (c1) rechercher une carte marquée (603, 605) par l'une desdites au moins deux unités de traitement dans ladite une de ladite pluralité de partitions (615, 617, 619, 621) ; et
    (c2) traiter (650, 670) un pointeur dans ladite carte marquée.
  5. Dispositif comportant au moins deux unités de traitement (205, 207) couplées à une mémoire tas partagée (209), ladite mémoire tas partagée étant accessible par lesdites au moins deux unités de traitement, dans lequel ledit dispositif comprend :
    (a) un premier mécanisme de détection configuré de manière à détecter (405, 453) une condition de lancement de regroupement de places en mémoire par l'une desdites au moins deux unités de traitement ;
    (b) un mécanisme de suspension de mutation, sensible au premier mécanisme de détection, configuré de manière à mettre en attente (408, 457) la mutation de ladite mémoire tas partagée par lesdites au moins deux unités de traitement ;
    (c) un mécanisme de lancement configuré de manière à lancer un traitement de regroupement de places en mémoire à générations (413, 463) dans lesdites au moins deux unités de traitement après que lesdites au moins deux unités de traitement aient mis en attente la mutation de ladite mémoire tas partagée en réponse au mécanisme de suspension de mutation ;
    (d) un deuxième mécanisme de détection configuré de manière à détecter (415, 465) l'achèvement dudit traitement de regroupement de places en mémoire à générations lancé par le mécanisme de lancement ;
    (e) un mécanisme de reprise, sensible au deuxième mécanisme de détection, configuré de manière à reprendre (419, 469) la mutation de ladite mémoire tas partagée par lesdites au moins deux unités de traitement ;
       caractérisé en ce que ladite mémoire tas partagée est une mémoire partagée à marquage de cartes (600), le mécanisme de lancement est configuré de manière à lancer un traitement de regroupement de places en mémoire à générations (413, 463) dans lesdites au moins deux unités de traitement, le deuxième mécanisme de détection est configuré de manière à détecter (415, 465) l'achèvement dudit traitement de regroupement de places en mémoire à générations dans lesdites au moins deux unités de traitement et le dispositif comprend, de plus :
    (f) un mécanisme de partitionnement configuré de manière à partitionner ladite mémoire tas partagée à marquage de cartes en une pluralité de partitions (615, 617, 619, 621) ; et
    (g) un mécanisme d'attribution configuré de manière à attribuer l'une desdites au moins deux unités de traitement à l'une de ladite pluralité de partitions.
  6. Dispositif selon la revendication 5, dans lequel le mécanisme de suspension de mutation comprend :
    (b1) un premier mécanisme de signalement configuré de manière à amener (408, 457) lesdites au moins deux unités de traitement à mettre en attente la mutation de ladite mémoire tas partagée ; et
    (b2) un premier mécanisme de retard configuré de manière à attendre (411, 461) que lesdites au moins deux unités de traitement mettent en attente la mutation de ladite mémoire tas partagée.
  7. Dispositif selon la revendication 5, dans lequel le deuxième mécanisme de détection comprend :
    (d1) un deuxième mécanisme de signalement configuré de manière à amener lesdites au moins deux unités de traitement à signaler (415, 465) que ledit traitement de regroupement de places en mémoire à générations est achevé ; et
    (d2) un deuxième mécanisme de retard configuré de manière à attendre (417, 467) que ledit traitement de regroupement de places en mémoire à générations soit achevé dans lesdites au moins deux unités de traitement.
  8. Dispositif selon l'une quelconque des revendications 5 à 7, dans lequel le mécanisme de lancement comprend, de plus :
    (c1) un mécanisme de recherche configuré de manière à rechercher une carte marquée (603, 605) par l'une desdites au moins deux unités de traitement dans ladite une de ladite pluralité de partitions ; et
    (c2) un mécanisme de traitement de pointeur (650, 670) configuré de manière à traiter un pointeur dans ladite carte marquée.
  9. Système contrôlé par un ordinateur comportant un dispositif selon l'une quelconque des revendications 6 à 8 dans lequel ledit dispositif est un ordinateur (200).
  10. Produit de programme informatique comprenant :
    un support de mémorisation utilisable par un ordinateur comportant un code pouvant être lu par un ordinateur mis en oeuvre sur celui-ci pour amener un ordinateur (200), comportant au moins deux unités de traitement (205, 207) couplées à une mémoire tas partagée (209), à effectuer la mutation et le regroupement de places en mémoire dans la mémoire tas partagée, ledit code pouvant être lu par un ordinateur comprend :
    (a) des dispositifs de code de programme pouvant être lus par un ordinateur configurés de manière à amener ledit ordinateur à mettre en oeuvre un premier mécanisme de détection configuré de manière à détecter (405, 453) une condition de lancement de regroupement de places en mémoire par l'une desdites au moins deux unités de traitement ;
    (b) des dispositifs de code de programme pouvant être lus par un ordinateur configurés de manière à amener ledit ordinateur à mettre en oeuvre un mécanisme de suspension de mutation, sensible au premier mécanisme de détection, configuré de manière à mettre en attente (408, 457) la mutation de ladite mémoire tas partagée par lesdites au moins deux unités de traitement ;
    (c) des dispositifs de code de programme pouvant être lus par un ordinateur configurés de manière à amener ledit ordinateur à mettre en oeuvre un mécanisme de lancement configuré de manière à lancer un traitement de regroupement de places en mémoire à générations (413, 463) après que lesdites au moins deux unités de traitement aient mis en attente la mutation de ladite mémoire tas partagée en réponse au mécanisme de suspension de mutation ;
    (d) des dispositifs de code de programme pouvant être lus par un ordinateur configurés de manière à amener ledit ordinateur à mettre en oeuvre un deuxième mécanisme de détection configuré de manière à détecter (415, 465) l'achèvement dudit traitement de regroupement de places en mémoire à générations lancé par le mécanisme de lancement ;
    (e) des dispositifs de code de programme pouvant être lus par un ordinateur configurés de manière à amener ledit ordinateur à mettre en oeuvre un mécanisme de reprise, sensible au deuxième mécanisme de détection, configuré de manière à reprendre (419, 469) la mutation de ladite mémoire tas partagée par lesdites au moins deux unités de traitement ;
       caractérisé en ce que lesdits dispositifs de code de programme pouvant être lus par un ordinateur sont configurés de manière à amener ledit ordinateur à mettre en oeuvre un mécanisme de lancement configuré de manière à lancer un traitement de regroupement de places en mémoire à générations (413, 463) dans lesdites au moins deux unités de traitement, ledit deuxième mécanisme de détection est configuré de manière à détecter (415, 465) l'achèvement dudit traitement de regroupement de places en mémoire à générations dans lesdites au moins deux unités de traitement et ladite mémoire tas partagée est une mémoire partagée à marquage de cartes (600) comprenant, de plus :
    (f) des dispositifs de code de programme pouvant être lus par un ordinateur configurés de manière à amener ledit ordinateur à mettre en oeuvre un mécanisme de partitionnement configuré de manière à partitionner ladite mémoire tas partagée à marquage de cartes en une pluralité de partitions (615, 617, 619, 621) ; et
    (g) des dispositifs de code de programme pouvant être lus par un ordinateur configurés de manière à amener ledit ordinateur à mettre en oeuvre un mécanisme d'attribution configuré de manière à attribuer l'une desdites au moins deux unités de traitement à l'une de ladite pluralité de partitions.
  11. Produit de programme informatique selon la revendication 10, dans lequel le mécanisme de suspension de mutation comprend :
    (b1) des dispositifs de code de programme pouvant être lus par un ordinateur configurés de manière à amener (408, 457) ledit ordinateur à mettre en oeuvre un premier mécanisme de signalement configuré de manière à amener lesdites au moins deux unités de traitement à mettre en attente la mutation de ladite mémoire tas partagée ; et
    (b2) des dispositifs de code de programme pouvant être lus par un ordinateur configurés de manière à amener ledit ordinateur à mettre en oeuvre un premier mécanisme de retard configuré de manière à attendre (411, 461) que lesdites au moins deux unités de traitement aient mis en attente la mutation de ladite mémoire tas partagée.
  12. Produit de programme informatique selon la revendication 10, dans lequel le deuxième mécanisme de détection comprend :
    (d1) des dispositifs de code de programme pouvant être lus par un ordinateur configurés de manière à amener ledit ordinateur à mettre en oeuvre un deuxième mécanisme de signalement configuré de manière à amener lesdites au moins deux unités de traitement à signaler (415, 465) que ledit traitement de regroupement de places en mémoire à générations est achevé ; et
    (d2) des dispositifs de code de programme pouvant être lus par un ordinateur configurés de manière à amener ledit ordinateur à mettre en oeuvre un deuxième mécanisme de retard configuré de manière à attendre (417, 467) que ledit traitement de regroupement de places en mémoire à générations soit achevé dans lesdites au moins deux unités de traitement.
  13. Produit informatique selon l'une quelconque des revendications 10 à 12, dans lequel le mécanisme de lancement comprend, de plus :
    (c1) des dispositifs de code de programme pouvant être lus par un ordinateur configurés de manière à amener ledit ordinateur à mettre en oeuvre un mécanisme de recherche configuré de manière à rechercher une carte marquée (603, 605) par l'une desdites au moins deux unités de traitement dans ladite une de ladite pluralité de partitions ; et
    (c2) des dispositifs de code de programme pouvant être lus par un ordinateur configurés de manière à amener ledit ordinateur à mettre en oeuvre un mécanisme de traitement de pointeur (650, 670) configuré de manière à traiter un pointeur dans ladite carte marquée.
EP98201604A 1997-05-30 1998-05-14 Procédé et dispositif de récupération des locations inutilisées d'une mémoire tas partagée utilisants plusieurs unités de traitement Expired - Lifetime EP0881576B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US866351 1997-05-30
US08/866,351 US6199075B1 (en) 1997-05-30 1997-05-30 Method and apparatus for generational garbage collection of a heap memory shared by multiple processors

Publications (2)

Publication Number Publication Date
EP0881576A1 EP0881576A1 (fr) 1998-12-02
EP0881576B1 true EP0881576B1 (fr) 2002-01-30

Family

ID=25347420

Family Applications (1)

Application Number Title Priority Date Filing Date
EP98201604A Expired - Lifetime EP0881576B1 (fr) 1997-05-30 1998-05-14 Procédé et dispositif de récupération des locations inutilisées d'une mémoire tas partagée utilisants plusieurs unités de traitement

Country Status (4)

Country Link
US (1) US6199075B1 (fr)
EP (1) EP0881576B1 (fr)
JP (1) JPH1115726A (fr)
DE (1) DE69803624T2 (fr)

Families Citing this family (69)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6560773B1 (en) * 1997-12-12 2003-05-06 International Business Machines Corporation Method and system for memory leak detection in an object-oriented environment during real-time trace processing
US6272504B1 (en) * 1998-05-07 2001-08-07 International Business Machines Corporation Flexibly deleting objects in a resource constrained environment
US6988271B2 (en) 1998-10-02 2006-01-17 Microsoft Corporation Heavyweight and lightweight instrumentation
US7039919B1 (en) * 1998-10-02 2006-05-02 Microsoft Corporation Tools and techniques for instrumenting interfaces of units of a software program
US6381735B1 (en) * 1998-10-02 2002-04-30 Microsoft Corporation Dynamic classification of sections of software
US6983463B1 (en) 1998-10-02 2006-01-03 Microsoft Corporation Network independent profiling of applications for automatic partitioning and distribution in a distributed computing environment
US6317756B1 (en) * 1998-10-07 2001-11-13 International Business Machines Corporation On-the-fly garbage collector
GB9825102D0 (en) * 1998-11-16 1999-01-13 Insignia Solutions Plc Computer system
US6308319B1 (en) * 1999-02-22 2001-10-23 Sun Microsystems, Inc. Thread suspension system and method using trapping instructions in delay slots
US6480862B1 (en) * 1999-04-23 2002-11-12 International Business Machines Corporation Relation-based ordering of objects in an object heap
US6363403B1 (en) * 1999-06-30 2002-03-26 Lucent Technologies Inc. Garbage collection in object oriented databases using transactional cyclic reference counting
US6381738B1 (en) * 1999-07-16 2002-04-30 International Business Machines Corporation Method for optimizing creation and destruction of objects in computer programs
US6324550B1 (en) 1999-08-25 2001-11-27 Bullant Technology Pty Ltd Data object identification and removal system
US6611858B1 (en) * 1999-11-05 2003-08-26 Lucent Technologies Inc. Garbage collection method for time-constrained distributed applications
US6502109B1 (en) * 1999-11-05 2002-12-31 Lucent Technologies Inc. Distributed communications system having garbage collecting virtual processes
US6681306B1 (en) * 1999-11-29 2004-01-20 Sun Microsystems, Inc. Method and apparatus for increasing scavenging garbage collection effectiveness
US6505344B1 (en) * 2000-01-12 2003-01-07 International Business Machines Corporation Object oriented apparatus and method for allocating objects on an invocation stack
US6658652B1 (en) * 2000-06-08 2003-12-02 International Business Machines Corporation Method and system for shadow heap memory leak detection and other heap analysis in an object-oriented environment during real-time trace processing
US6865585B1 (en) * 2000-07-31 2005-03-08 Microsoft Corporation Method and system for multiprocessor garbage collection
CA2421591C (fr) 2000-09-13 2011-08-23 Geodesic Systems, Incorporated Ramasse-miettes conservatif pouvant etre utilise avec des allocateurs de memoire generaux
US6968557B1 (en) * 2000-12-18 2005-11-22 Stratum8 Corporation Reducing stack memory resources in a threaded computer system
US6804681B2 (en) * 2001-05-08 2004-10-12 Sun Microsystems, Inc. Identifying and tracking object references in a java programming environment
US7065747B2 (en) * 2001-05-08 2006-06-20 Sun Microsystems, Inc. Identifying references to objects during bytecode verification
US6499094B1 (en) * 2001-09-14 2002-12-24 Unisys Corporation Management of memory heap space for data files accessible to programs operating in different addressing modes
US20030172094A1 (en) * 2002-03-06 2003-09-11 International Business Machines Corporation Automatic file system maintenance
US6950838B2 (en) * 2002-04-17 2005-09-27 Sun Microsystems, Inc. Locating references and roots for in-cache garbage collection
US6898602B2 (en) * 2002-04-22 2005-05-24 Sun Microsystems Inc. Measuring the exact memory requirement of an application through intensive use of garbage collector
JP4079684B2 (ja) * 2002-05-08 2008-04-23 株式会社日立製作所 ヒープメモリ管理方法およびそれを用いた計算機システム
GB0212119D0 (en) * 2002-05-25 2002-07-03 Ibm A method and system for the garbage collection of shared data
US6928460B2 (en) * 2002-07-01 2005-08-09 Sun Microsystems, Inc. Method and apparatus for performing generational garbage collection in a segmented heap
US6991289B2 (en) * 2002-07-31 2006-01-31 Harman International Industries, Incorporated Seatback audio system
US20040107227A1 (en) * 2002-12-03 2004-06-03 International Business Machines Corporation Method for efficient implementation of dynamic lock-free data structures with safe memory reclamation
JP4116877B2 (ja) * 2002-12-26 2008-07-09 富士通株式会社 ヒープサイズ自動最適化処理方法，ヒープサイズ自動最適化装置およびそのプログラム
US7472246B2 (en) * 2003-04-30 2008-12-30 International Business Machines Corporation Method and system for automated memory reallocating and optimization between logical partitions
US7299469B2 (en) * 2003-04-30 2007-11-20 International Business Machines Corporation Hierarchical weighting of donor and recipient pools for optimal reallocation in logically partitioned computer systems
US7478393B2 (en) * 2003-04-30 2009-01-13 International Business Machines Corporation Method for marketing to instant messaging service users
US7325062B2 (en) * 2003-04-30 2008-01-29 International Business Machines Corporation Method and system for automated adapter reallocation and optimization between logical partitions
US7313796B2 (en) * 2003-06-05 2007-12-25 International Business Machines Corporation Reciprocity and stabilization in dynamic resource reallocation among logically partitioned systems
US7237139B2 (en) * 2003-08-07 2007-06-26 International Business Machines Corporation Services heuristics for computer adapter placement in logical partitioning operations
US7376684B2 (en) * 2004-06-04 2008-05-20 International Business Machines Corporation Efficient parallel bitwise sweep during garbage collection
US7149866B2 (en) * 2004-06-04 2006-12-12 International Business Machines Corporation Free item distribution among multiple free lists during garbage collection for more efficient object allocation
EP1622009A1 (fr) * 2004-07-27 2006-02-01 Texas Instruments Incorporated Architecture et systèmes JSM
US7272695B1 (en) * 2004-09-13 2007-09-18 Sun Microsystems, Inc. Hot-card caching to avoid excessive remembered-set updating
US8452938B1 (en) * 2004-12-30 2013-05-28 Azul Systems, Inc. Garbage collection with memory quick release
US7424589B1 (en) * 2005-06-24 2008-09-09 Sun Microsystems, Inc. Method and an apparatus for the high-precision tracking of approximate per-task memory usage
US7389395B1 (en) 2005-06-26 2008-06-17 Sun Microsystems, Inc. Split-reference, two-pass mark-compaction
US20070118579A1 (en) * 2005-11-21 2007-05-24 Hudson Richard L Dynamic consistency between multiple versions of objects managed by a garbage collector using transactional memory support
WO2008005298A2 (fr) * 2006-06-30 2008-01-10 Wms Gaming Inc. Systèmes et procédés de gestion de mémoire dans des machines de jeux de pari
US8202168B2 (en) * 2006-06-30 2012-06-19 Wms Gaming Inc. Systems and methods for managing memory in wagering game machines
US8868623B2 (en) * 2007-10-30 2014-10-21 International Business Machines Corporation Enhanced garbage collection in a multi-node environment
US9208081B1 (en) * 2007-11-30 2015-12-08 Oracle America, Inc. Concurrent object management
US8239865B2 (en) * 2008-06-02 2012-08-07 Microsoft Corporation Waiting and synchronization of parallel task executions based on task groups and task object representations
US20100017583A1 (en) * 2008-07-15 2010-01-21 International Business Machines Corporation Call Stack Sampling for a Multi-Processor System
US9418005B2 (en) * 2008-07-15 2016-08-16 International Business Machines Corporation Managing garbage collection in a data processing system
US8286134B2 (en) * 2008-07-15 2012-10-09 International Business Machines Corporation Call stack sampling for a multi-processor system
JP4555879B2 (ja) * 2008-08-11 2010-10-06 株式会社日立製作所 メモリ管理方法、メモリ管理プログラム、および、メモリ管理装置
US8301672B2 (en) * 2008-09-22 2012-10-30 Advanced Micro Devices, Inc. GPU assisted garbage collection
US8473900B2 (en) * 2009-07-01 2013-06-25 Advanced Micro Devices, Inc. Combining classes referenced by immutable classes into a single synthetic class
US8200718B2 (en) * 2009-07-02 2012-06-12 Roberts Michael L Parallelized, incremental garbage collector
US8327109B2 (en) * 2010-03-02 2012-12-04 Advanced Micro Devices, Inc. GPU support for garbage collection
US9176783B2 (en) 2010-05-24 2015-11-03 International Business Machines Corporation Idle transitions sampling with execution context
US8843684B2 (en) 2010-06-11 2014-09-23 International Business Machines Corporation Performing call stack sampling by setting affinity of target thread to a current process to prevent target thread migration
US8799872B2 (en) 2010-06-27 2014-08-05 International Business Machines Corporation Sampling with sample pacing
US8799904B2 (en) 2011-01-21 2014-08-05 International Business Machines Corporation Scalable system call stack sampling
US10528254B2 (en) * 2011-04-26 2020-01-07 Brian J. Bulkowski Methods and systems of garbage collection and defragmentation in a distributed database
WO2013018593A1 (fr) * 2011-07-29 2013-02-07 日本電気株式会社 Appareil de traitement d'informations, système de traitement d'informations, procédé de traitement d'informations et support de stockage de programme de commande
US9740716B2 (en) * 2013-08-21 2017-08-22 Oracle International Corporation System and method for dynamically selecting a garbage collection algorithm based on the contents of heap regions
US20150254011A1 (en) * 2014-03-10 2015-09-10 Kabushiki Kaisha Toshiba Memory system, memory controller and control method of non-volatile memory
US9747204B2 (en) 2015-12-17 2017-08-29 International Business Machines Corporation Multi-section garbage collection system including shared performance monitor register

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB1548401A (en) * 1975-10-08 1979-07-11 Plessey Co Ltd Data processing memory space allocation and deallocation arrangements
US4757438A (en) 1984-07-12 1988-07-12 Texas Instruments Incorporated Computer system enabling automatic memory management operations
US4775932A (en) * 1984-07-31 1988-10-04 Texas Instruments Incorporated Computer memory system with parallel garbage collection independent from an associated user processor
US4920483A (en) 1985-11-15 1990-04-24 Data General Corporation A computer memory for accessing any word-sized group of contiguous bits
US5222221A (en) 1986-06-17 1993-06-22 Yeda Research And Development Co., Ltd. Method and apparatus for implementing a concurrent logic program
US4797810A (en) * 1986-06-26 1989-01-10 Texas Instruments Incorporated Incremental, multi-area, generational, copying garbage collector for use in a virtual address space
US4907151A (en) 1988-09-30 1990-03-06 Digital Equipment Corporation System and method for garbage collection with ambiguous roots
US5088036A (en) * 1989-01-17 1992-02-11 Digital Equipment Corporation Real time, concurrent garbage collection system and method
WO1991014986A1 (fr) 1990-03-23 1991-10-03 Eastman Kodak Company Gestion de memoire virtuelle et agencement d'affectation pour systeme de traitement de donnees numeriques
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
US5193180A (en) 1991-06-21 1993-03-09 Pure Software Inc. System for modifying relocatable object code files to monitor accesses to dynamically allocated memory
US5355483A (en) 1991-07-18 1994-10-11 Next Computers Asynchronous garbage collection
JP3628032B2 (ja) * 1992-06-15 2005-03-09 マイクロソフト コーポレーション コンサーバティブ・スタックとジェネレイショナル・ヒープガーベージ・コレクション用コンピュータシステム及び方法
DE69327089T2 (de) 1992-07-24 2000-04-13 Microsoft Corp Rechnerverfahren und system zur zuordnung und zur freigabe von speichern.
DE4234112C1 (de) * 1992-10-09 1993-10-14 Keller Grundbau Gmbh Verfahren zur Gewinnung von Deponieraum durch Müllstopfverdichtung
US5416915A (en) * 1992-12-11 1995-05-16 International Business Machines Corporation Method and system for minimizing seek affinity and enhancing write sensitivity in a DASD array
US5560003A (en) 1992-12-21 1996-09-24 Iowa State University Research Foundation, Inc. System and hardware module for incremental real time garbage collection and memory management
US5408650A (en) 1993-06-29 1995-04-18 Digital Equipment Corporation Memory analysis system for dynamically displaying memory allocation and de-allocation events associated with an application program
US5566321A (en) 1993-12-13 1996-10-15 Cray Research, Inc. Method of managing distributed memory within a massively parallel processing system
US5819299A (en) * 1996-06-06 1998-10-06 Electric Communities Process for distributed garbage collection
US5845298A (en) * 1997-04-23 1998-12-01 Sun Microsystems, Inc. Write barrier system and method for trapping garbage collection page boundary crossing pointer stores
US5842016A (en) * 1997-05-29 1998-11-24 Microsoft Corporation Thread synchronization in a garbage-collected system using execution barriers
US5873104A (en) * 1997-06-26 1999-02-16 Sun Microsystems, Inc. Bounded-pause time garbage collection system and method including write barrier associated with source and target instances of a partially relocated object
US5857210A (en) * 1997-06-26 1999-01-05 Sun Microsystems, Inc. Bounded-pause time garbage collection system and method including read and write barriers associated with an instance of a partially relocated object

Also Published As

Publication number Publication date
EP0881576A1 (fr) 1998-12-02
US6199075B1 (en) 2001-03-06
JPH1115726A (ja) 1999-01-22
DE69803624T2 (de) 2002-09-12
DE69803624D1 (de) 2002-03-14

Similar Documents

Publication Publication Date Title
EP0881576B1 (fr) Procédé et dispositif de récupération des locations inutilisées d'une mémoire tas partagée utilisants plusieurs unités de traitement
Flood et al. Parallel garbage collection for shared memory multiprocessors
EP0969377B1 (fr) Procédé de regroupement des locations inutilisées à base de réplication dans un système multiprocesseur
US5809554A (en) User control of multiple memory heaps
KR100541174B1 (ko) 로컬화된 메모리 재이용을 가진 데이터 처리기
EP1105804B1 (fr) Procede, dispositif et article industriel simplifiant la gestion des ressources dans le cas d'applications comportant deux types de code de programme
US6671707B1 (en) Method for practical concurrent copying garbage collection offering minimal thread block times
US5920876A (en) Performing exact garbage collection using bitmaps that identify pointer values within objects
EP0874318B1 (fr) Procédé et dispositif de traitement numérique permettant de localiser des pointeurs pour collecter des objets de données inutiles
US5088036A (en) Real time, concurrent garbage collection system and method
US6115782A (en) Method and apparatus for locating nodes in a carded heap using a card marking structure and a node advance value
US6826583B1 (en) Local allocation buffers for parallel garbage collection
US7962707B2 (en) Apparatus and method for deterministic garbage collection of a heap memory
US5915255A (en) Method and apparatus for referencing nodes using links
EP0173464A2 (fr) Système de mémoire d'ordinateur à regroupement parallèle des positions inutilisées indépendant d'un processeur d'usager associé
EP0864982A1 (fr) Processeur de données numériques avec attribution de points de contrÔle et branchement multiple
US7376940B1 (en) Thread suspension and method in a multi-threaded environment
US5911144A (en) Method and apparatus for optimizing the assignment of hash values to nodes residing in a garbage collected heap
Hudson et al. Sapphire: Copying GC without stopping the world
JP2002506550A (ja) 部分的に再配置されたオブジェクトのソース及び目標インスタンスに関する書込みバリアを含む有界休止時間ガーベッジコレクションシステム及び方法
JP2002506549A (ja) 部分的に再配置されたオブジェクトのソースインスタンスに関連する書き込みバリアを含む有界休止時間ガーベッジコレクションシステム及びその方法
WO2001013240A1 (fr) Dispositif de recuperation de l'espace memoire a algorithme train utilisant un seuil d'objet surdimensionne reduit
WO2001013238A1 (fr) Recuperateur d'espace memoire a base d'algorithme d'apprentissage utilisant un indicateur de benne la plus avancee
North et al. Concurrent garbage collection on stock hardware
US20090150465A1 (en) Object Deallocation System and Method

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB NL SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SUN MICROSYSTEMS, INC.

17P Request for examination filed

Effective date: 19990510

17Q First examination report despatched

Effective date: 19990617

AKX Designation fees paid

Free format text: DE FR GB NL SE

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

RTI1 Title (correction)

Free format text: METHOD AND APPARATUS FOR GENERATIONAL GARBAGE COLLECTION IN A SHARED HEAP MEMORY BY MEANS OF MULTIPLE PROCESSOR UNITS

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

REG Reference to a national code

Ref country code: GB

Ref legal event code: IF02

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): DE FR GB NL SE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20020130

REF Corresponds to:

Ref document number: 69803624

Country of ref document: DE

Date of ref document: 20020314

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20020430

ET Fr: translation filed
NLV1 Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents act
PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed
PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20040510

Year of fee payment: 7

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20040512

Year of fee payment: 7

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20040527

Year of fee payment: 7

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20050514

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20051201

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20050514

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20060131

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20060131