JP2009199391A - Garbage collection method, and its execution device, and processing program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To prevent all threads from stopping at garbage collection when executing a program with multi-thread. <P>SOLUTION: A method includes the steps of: storing contents of a first heap area, in which an object that is referred or updated by the program is stored, in a second heap area; changing the heap area, in which the garbage collection is executed, from the first heap area to the second heap area: executing the garbage collection in the second heap area, and also continuously executing the program even during execution of the garbage collection; and changing a reference route from the first heap area to the second heap area after the execution of the garbage collection in the second heap area. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

The present invention relates to garbage collection of objects stored in a memory in a language processing system.

  Garbage collection (hereinafter referred to as GC) is a means for implicitly releasing objects stored in a heap area in a memory in a language processing system. The GC determines whether an object in the heap area can be used at that time (hereinafter referred to as alive), and releases the object that is determined not to be alive from the heap area. There are various GC methods, and each method has its advantages.

  One of the GC methods is the Stop & Copy method. In this method, the execution of the program is stopped, and the heap area prepared separately from the original heap area that can be traced from the source from which the program can trace the reference (hereinafter referred to as the reference route) To copy. The object that can be traced from the copied object is further copied to another same area. By repeating this, only the surviving objects are copied to another area, the entire original heap area is discarded together with the non-living objects, and the program continues to execute using the other area as a heap area.

  One of the other methods is the Mark & Sweep method. In this method, execution of the program is stopped, all objects that can be traced from the reference route are marked (marked), and then objects that are not marked are discarded (swept).

  These two methods have the advantage that the Mark & Sweep method is superior in GC execution time, and the Stop & Copy method is faster in assigning new data to the memory (Non-patent Document 1).

  Java (TM) Virtual Machine (hereinafter referred to as JavaVM), one of the language processing systems (Java and all Java-related trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries) Is a generational GC that combines the Mark & Sweep method and the Stop & Copy method (Patent Document 1). This method combines the advantages of the Stop & Copy method and the Mark & Sweep method. Divide the heap area into two, place the object with a short lifetime in one area, perform the GC with the Stop & Copy method, and add the one with the long lifetime. Place in one area and perform GC with Mark & Sweep method. The Stop & Copy method is suitable for areas that handle objects with a short lifetime, and the Mark & Sweep method is applied to areas that have many objects with a long lifetime.

  Although improvement of GC execution time has been studied as described in Patent Document 1, a problem of program stoppage occurring during GC execution still occurs. Although research has also been conducted on a method of performing this program without causing a program stop time, it is difficult to prevent the program from being completely stopped, and the overhead is large. Japanese Patent Application Laid-Open No. 2004-228561 discloses a technique for reducing overhead generated in parallel execution of a program and a GC in the Stop & Copy method. However, there is still a complete stop of the program.

Toshio Endo, “Garbage Collection as General Education” http://matsu-www.is.titech.ac.jp/~endo/gc/gc.pdf, p.11 Special Table 2003-515812 Japanese Patent Laid-Open No. 2001-184254

  In the process of releasing an object by GC, program execution is generally stopped. This is because the state of the heap area changes due to the GC processing, and it is difficult to execute in parallel with the execution of the program that also changes the state of the heap area.

  The program stop time generated by GC is proportional to the number of objects alive, the size of the GC area, etc. depending on the method, but the amount of objects handled by the language processing system and the size of the heap area are There is a tendency to increase due to improvement in semiconductor technology, and the stop time is extended regardless of the method.

  In the present invention, in order to reduce the suspension of program execution by GC, in a language processing system in a multi-thread environment, program execution is continued even during GC processing, and the suspension of all threads by GC is reduced. Objective.

  In order to achieve the above object, a function for replicating the heap area of the language processing system is provided. A function to change the GC that is originally performed on the replication source to be performed on the new heap area is provided, and the program operation is performed in parallel on the replication heap area. After the GC ends, the program stop time by GC is reduced by providing a function to switch the program operation to be executed in the new heap area.

  In addition, after the program execution has been switched to a new area, from the start of replication of the area until the GC ends in the new area, the function that remembers the updated location of the program that was executed in parallel in the original heap area Have a table. Also, since the object may move in the new heap area due to GC performed in the new area, remember the amount of movement in the table. Then, based on the updated position and the amount moved, a function is provided to reflect the update performed in the copy source area after the end of the GC in the new heap area to the new area. Since the program continues to execute during the reflection process, the program refers to the function when it detects that the updated object is referenced in the copy source area that exists in the new area. Provide a function to stop only the thread.

  According to the present invention, since the heap area for performing GC and the heap area for executing the program can be separated, the program can be executed in parallel even during the execution of the GC. As a result, the cause of stopping the program during the execution of the GC is solved, so that the program stop can be reduced.

  Hereinafter, an embodiment in which Java VM 107 is used as a language processing system operating on the computer system 101 will be described in detail with reference to the drawings.

  FIG. 1 is a diagram of the configuration of the JavaVM and its input / output data according to the embodiment. The computer system 101 executes the JavaVM 107 stored in the main memory (memory) 105, the central processing unit 130 loads the JavaVM 107, the main memory 105 in which various areas are secured, and an auxiliary storage device in which files and the like are stored The main memory 105 and the central processing unit 130 are coupled by a bus 128. The data area 109 is a storage area reserved for the Java VM 107 to hold data, and among them, the storage area to which objects are allocated is the Java heap area 110. The method reading unit 108 and the method execution unit 118 are programs constituting the language processing system.

  The Java source file 104 stored in the auxiliary storage device 102 is converted by the Java compiler 106 into a Java class file 103 that holds a Java bytecode in a format that can be interpreted and executed by the JavaVM 107, and this is input to the JavaVM 107. The Java class file 103 input to the Java VM 107 is analyzed by the method reading unit 108 and creates method information 113 in the data area 109. The method execution unit 118 is assigned a thread from the thread mechanism 126, reads the method information 113, and manipulates the processing content held in the method information 113 by operating an object in the Java heap area 110 from the reference route 114. Execute the method.

  The object of this embodiment relates to a GC that releases an object created in the Java heap area 110 by the method execution unit 118 when a method is executed. The GC automatically detects and releases an object that is no longer necessary for the Java VM 107. This is because the GC execution unit 121 in the Java heap management unit 120 is assigned a thread from the thread mechanism 126, and the GC execution unit 121 Determines the necessity of the object in the Java heap area 110 and releases the object. Both the processing by the GC execution unit 121 and the processing by the method execution unit 118 are assigned threads from the thread mechanism 126, but both are processing for the Java heap area 110 and are difficult to perform at the same time. During the processing, all threads assigned to the method execution unit 118 must be stopped. The present invention has been devised to reduce all thread stops that occur during the GC process.

  A program for causing a computer to function as each processing unit is recorded on a recording medium such as a CD-ROM and stored in a magnetic disk or the like, and then loaded into a memory and executed. The recording medium for recording the program may be a recording medium other than the CD-ROM. The program may be used by installing it from the recording medium into the information processing apparatus, or the program may be used by accessing the recording medium through a network.

  FIG. 2 is a flowchart in the JavaVM 107 of this embodiment. First, the copy unit 123 of the Java heap copy unit 122 duplicates the Java heap area 110 to generate the Java heap area (new) 112, and the Java heap copy unit 122 converts the Java heap area 110 to the Java heap area (old) 111. And This process is a Java heap area copy process 201.

  After the processing is completed, the thread control unit 125 performs the GC processing normally performed in the Java heap area (old) 111 on the Java heap area (new) 112 for the thread allocated from the thread mechanism 126 to the GC execution unit 121. As is done, the information in the storage device indicating the Java heap area where the GC processing is performed is changed. Further, when the position of the object moves in the GC process, the GC execution unit 121 records the amount of movement in the movement offset table 115. This process is a Java heap area (new) GC process 202.

  During the operations of the Java heap area copy process 201 and the Java heap area (new) GC process 202, the method execution unit 118 executes the program in parallel in the Java heap area (old) 111. During this process, the update table management unit 117 stores in the update management table 116 that the method execution unit 118 has updated the data in the Java heap area (old) 111. This processing is the update table management processing of FIG. 10, and this update management table 116 is used for the subsequent processing.

  Next, the reference management unit 124 changes the information in the storage device indicating the reference route 114 pointing to the Java heap area (old) 111 to point to the Java heap area (new) 112 and switches the reference route. Prior to this processing, the reference route 114 points to the Java heap area (old) 111, so the method execution unit 118 performs processing on the Java heap area (old) 111. By changing the reference route 114 to point to the Java heap area (new) 112, the program that is operated by the method execution unit 118 operates in the Java heap area (new) 112. This process is an area switching process 203.

  Finally, the reference management unit 124 updates the data that the method execution unit 118 performed in the Java heap area (old) 111 during the Java heap area copy process 201 and the Java heap area (new) GC process 202 in the Java heap area ( New) Reflected in 112. Since the position of the data updated in the Java heap area (old) 111 is recorded in the update management table 116, the Java heap area of the data in the Java heap area (old) 111 is determined from the position and the movement offset table 115. (New) The position at 112 can be calculated. Based on this calculation result, the data in the Java heap area (old) 111 is overwritten in the Java heap area (new) 112. Thereafter, the Java heap copy unit 122 releases the Java heap area (old) 111 and sets the Java heap area (new) 112 as the Java heap area 110. This processing is Java heap area (old) update content reflection processing 204.

  During operation of the area switching process 203 and the Java heap area (old) update content reflection process 204, the method execution unit 118 executes the program in parallel in the Java heap area (new) 112. Before the area switching process 203 ends, the reference execution route 114 refers to the Java heap area (old) 111, so that the method execution unit 118 tries to operate on the Java heap area (old) 111. Therefore, the exception processing unit 119 detects that the method execution unit 118 is about to operate on the Java heap area (old) 111 and changes the reference route 114 to point to the Java heap area (new) 112. Before the Java heap area (old) update content reflection processing 204 is finished, the method execution unit 118 references the data in the Java heap area (new) 112 corresponding to the updated data in the Java heap area (old) 111. If you do, update contents already done in Java heap area (old) 111 will not be handled correctly. Therefore, the exception processing unit 119 detects that the method execution unit 118 tries to refer to the data in the Java heap area (new) 112 corresponding to the updated data in the Java heap area (old) 111, and Only the thread assigned from the thread mechanism 126 to the method execution unit 118 that has made the reference is stopped. The thread to be stopped is resumed at the end of the Java heap area (old) update content reflection process 204. This process is the reference exception process of FIG.

  With the above processing, in this embodiment, the Java heap area 110 that has not been subjected to GC processing before the execution can perform the GC processing while executing the program by the method execution unit 118. It is possible to realize a state in which the area 110 is normally performing GC processing despite the parallel operation of the program.

  FIG. 3 is a diagram illustrating at which timing each process of the embodiment is performed. As described above, the update table management process of FIG. 10 is executed in parallel with the Java heap area copy process 201 and the Java heap area (new) GC process 202, and the reference exception process of FIG. And the Java heap area (old) update content reflection processing 204 are executed in parallel. For this reason, the update table management process of FIG. 10 and the reference exception process of FIG. 11 are not executed simultaneously.

  FIG. 4 is a diagram showing the update management table 116. Update management when the method execution unit 118 updates the object existing in the Java heap area (old) 111 by executing the program during the operation of the Java heap area copy process 201 and the Java heap area (new) GC process 202 Change the value in table 116. The value of this table can be expressed by 1 bit because it is only necessary to record whether or not the object has been updated. In addition, it is required to manage all objects existing in the Java heap area (old) 111, but if this is done, the size of the table will increase. Therefore, the Java heap area (old) 111 is logically divided and managed for each. Therefore, it is only necessary to change the value of the table to 1 when there are one or more updated objects 401 in the divided area. When there is only an object 402 that has not been updated, the value of the table is set to 0. Just leave it.

  FIG. 5 is a diagram showing the movement offset table 115. The move offset table 115 records how many addresses other than the object 501 that disappears in the GC process are moved by the GC process in the GC process performed by the GC execution unit 121 during the Java heap area (new) GC process 202 It is a table to do. It is undefined how the object moves due to the GC, and it is necessary for calculating where in the Java heap area (new) 112 the object that was in the Java heap area (old) 111 exists. It is not necessary to record for all objects, it is only necessary to record objects other than the object 501 that disappears by GC processing, and for objects that have the same movement amount by GC processing, such as neighboring objects What is necessary is just to record collectively as one data.

  FIG. 6 is a flowchart showing the Java heap area copy process 201. The Java heap copy unit 122 sets the Java heap area 110 where the program is currently running by the method execution unit 118 as the Java heap area (old) 111 (step 601). Thereafter, the data in the Java heap area (old) 111 is copied by the copy unit 123, thereby generating the Java heap area (new) 112.

  The data in the Java heap area (old) 111 is an object, and all objects in the Java heap area (old) 111 are actually copied. Therefore, since copying is performed in order from the top of the Java heap area (old) 111, it is first determined whether the copy unit 123 has copied all the data (step 602). If all the data has not been copied, it is necessary to copy the data.

  As for the data to be copied here, the reference data should not be copied as it is. FIG. 7 shows the reason why the reference data and the reference data should not be copied as they are. Here, it is assumed that there is a memory address 703 and a numerical value 704 for deriving the object B702 as data held by the object A701. The pointer 705 from the object A701 to the memory address 703 of the object B702 is reference data. If this value is copied as it is and the object A701 is generated in the Java heap area (new), the address 703 of the memory is stored. Since the numerical value remains as it is, it becomes a pointer 707 to the object B702 in the Java heap area (old) 111. Therefore, by adding the address difference 706 between the Java heap area (old) 111 and the Java heap area (new) 112 to the memory address 703, the pointer 708 to the object B702 in the Java heap area (new) 112 is obtained. .

  For these reasons, it is necessary to determine whether the value to be copied is a reference or not (step 603). If it is not a reference, the value as it is is copied to the Java heap area (new) 112 (step 604). In the case of reference, copying is performed by increasing the value to be copied by the difference between the addresses of the Java heap area (old) 111 and the Java heap area (new) 112 (step 605). As a result, the reference value also points to the Java heap area (new) 112. When processing has been performed on all the data in the Java heap area (old), the Java heap area copy process 201 is terminated (step 602).

  FIG. 8 is a flowchart showing the Java heap area (new) GC process 202. Originally, the GC execution unit 121 is assigned a thread from the thread mechanism 126 and performs GC processing in the Java heap area 110. Actually, the Java heap area 110 is a Java heap area (old) 111. Here, the thread control unit 125 switches the GC process to be performed in the Java heap area (new) 112 for the thread assigned by the thread mechanism 126 to the GC execution unit 121 (step 801). As a result, the GC execution unit 121 performs GC processing in the Java heap area (new) 112 (step 802). As described in FIG. 5, the object moved by the GC process must be recorded in the movement offset table 115 (step 803).

  FIG. 9 is a flowchart showing the area switching process 203. Here, the reference route 114 points to the Java heap area (old) 111 so as to point to the Java heap area (new) 112. The problem here is that the program is executed by the method execution unit 118 in parallel with this processing. Therefore, if the method execution unit 118 references the object before the method execution unit 118 updates the Java heap area (old) 111 to the Java heap area (new) 112, the result becomes invalid. End up. A method of detecting that the method execution unit 118 has attempted to perform illegal execution will be described with reference to FIG. The update management table 116 shows the position of the object 401 updated in the Java heap area (old) 111. First, the position where the updated object 401 exists in the Java heap area (new) 112 is calculated. It is the position of the Java heap area (old) 111 of the updated object 401, the difference 706 between the addresses of the Java heap area (old) 111 and the Java heap area (new) 112, and the movement offset table 115 corresponding to the updated object 401 Is the position of the updated object 401 in the Java heap area (new) 112. This area is set as a guard area 1002 so that an exception occurs when the method execution unit 118 refers to data for this object. In order to realize the above, the following processing is performed.

  First, it is determined whether or not all the update management tables 116 have been processed (step 901). If not completed, the following processing is performed on the updated object 401 in the update management table 116. First, it is determined whether or not the updated object 401 is registered in the movement offset table 115 (step 902). The reason for doing this is that it is necessary to determine the object 1101 generated in the Java heap area (old) 111 after the Java heap area copy processing 201.

  FIG. 11 shows a state where an object 1101 generated in the Java heap area (old) 111 after the Java heap area copy process 201 exists. An object that is not registered in the movement offset table 115 is an object 501 that disappears in the GC process or an object 1101 that is generated in the Java heap area (old) 111 after the Java heap area copy process 201. Also, the object 501 that disappears in the GC process is an object that is not referenced from anywhere and cannot be updated. Therefore, an object registered in the update management table 116 and an object not registered in the movement offset table 115 can be determined as an object generated after the Java heap area copy process 201.

  If an object generated after the Java heap area copy processing 201 does not exist in the Java heap area (new) 112, there will be inconvenience in the subsequent Java heap area (old) update content reflection processing 204. In the case of an object 1101 generated in the Java heap area (old) 111 after the area copy processing 201, a dummy object 1102 having no information is generated in the Java heap area (new) 112 (step 903). Then, this dummy object 1102 is registered in the movement offset table 115 (step 904). The data held by the dummy object 1102 need not be defined in particular and may be an indefinite value 1103. The dummy object 1102 has the same size as the object 1101 generated in the Java heap area (old) 111 after the Java heap area copy processing 201. It only has to be.

  After step 904 is completed or when it is determined that the object 401 updated in step 902 is registered in the movement offset table 115, the Java heap area (new) 112 corresponding to the dummy object 1102 or the updated object 401 is displayed. The object located at is a guard area (step 905).

  After the above processing is completed, the reference route 114 pointing to the Java heap area (old) 111 is changed to point to the Java heap area (new) 112. First, the entire Java heap area (old) 111 is set as a guard area (step 906). This is to detect a case in which the Java heap area (old) 111 is referred to before switching to the Java heap area (new) 112 by a program executed in parallel with the area switching processing 203 by the method execution unit 118.

  After this processing, all reference routes 114 are set as guard areas (step 907). In the middle of switching the reference route 114, point to another Java heap area (old) 111 so that the reference route 114 once switched to the Java heap area (new) 112 points to the Java heap area (old) 111 This is because the reference route 114 is not overwritten. FIG. 12 shows the state of the reference route 114, the Java heap area (old) 111, and the Java heap area (new) 112 after performing Step 906 and Step 907.

  After step 906 and step 907 are completed, switching processing is performed for all reference routes 114. If all the reference routes 114 point to the Java heap area (new) 112, the processing has ended. If not, the processing has not yet ended (step 908). If processing is not completed, release the guard area of the reference route 114 for each reference route 114 and change the reference route 114 from the Java heap area (old) 111 to the Java heap area (new) 112 (Step 909). In order to change the reference pointing to the Java heap area (old) 111 to point to the Java heap area (new) 112, the position in the Java heap area (new) 112 must be calculated. This calculation can be performed by the same calculation method as that used when the updated object 401 in the Java heap area (new) 112 is used as a guard area. After changing all the reference routes 114 to point to the Java heap area (new) 112, the guard area applied to the entire Java heap area (old) 111 is released (step 910). The area switching process 203 is performed by a series of these processes.

  FIG. 13 is a flowchart showing the Java heap area (old) update content reflection process 204. Since the Java heap area (old) update content reflection processing 204 needs to reflect all the update contents registered in the update management table 116, first, it is determined whether all the update contents are reflected (step 1301). . If all the updated contents are not reflected, the guard area applied to the object in the unreflected Java heap area (new) 112 is released (step 1302).

  Then, the object in the Java heap area (new) 112 needs to have the same contents as the data in the Java heap area (old), but as with the Java heap area copy process 201, the reference If only the value is overwritten, the Java heap area (old) 111 will be pointed to. Therefore, it is determined whether or not the data value of the updated object 401 is a reference (step 1303). If it is not a reference, the value as it is is overwritten in the Java heap area (new) 112 (step 1304). In the case of reference, the reference is changed from the Java heap area (old) 111 to the Java heap area (new) 112 by the same method as in step 909 of the area switching process 203 (step 1305).

  After all the update reflection processes are completed, the Java heap copy unit 120 changes the Java heap area (new) 112 to be handled as the Java heap area 110 (step 1306). Thereafter, the Java heap area (old) 111 that is no longer needed is released (step 1307). Finally, the execution of the program by the method execution unit 118 is returned to the normal state by resuming all threads that have been stopped by the exception processing unit 119 described later (step 1308).

  At the same time as causing the method execution unit 118 to execute the program execution by the Java heap area copy process 201, the Java heap area (new) GC process 202, the area switching process 203, and the Java heap area (old) update content reflection process 204. GC processing can be performed in parallel. However, the processing of the update table management unit 117 that updates the update management table 116 and the processing that is performed when the method execution unit 118 refers to an area that becomes invalid if it is referred to when executing the program are not described. These are described below.

  FIG. 14 is a flowchart showing the update table management process. As described in FIG. 2, the update performed by the method execution unit 118 in the Java heap area (old) 111 only needs to be recorded during the Java heap area copy process 201 and the Java heap area (new) GC process 202. Therefore, the update table management unit 117 determines whether the Java heap area copy process 201 and the Java heap area (new) GC process 202 are currently in progress (step 1401). If the Java heap area copy process 201 and the Java heap area (new) GC process 202 are not in the middle of processing, the process of the update table management unit 117 ends. When the Java heap area copy process 201 and the Java heap area (new) GC process 202 are in the middle, the method execution unit 118 determines whether the Java heap area (old) 111 has been updated (step 1402). ). When update processing is performed for the Java heap area (old) 111, record that the update is performed by manipulating the bit of the update management table 116 corresponding to the position of the object in the Java heap area (old) 111 (step) 1403).

  FIG. 15 is a flowchart showing the reference exception process. The exception processing unit 119 supplements the exception generated by the method execution unit 118 during the execution of the program and executes the following processing. An exception occurs when the method execution unit 118 references a guard area that has been applied to the reference route 114, Java heap area (old) 111, and Java heap area (new) 112 in the area switching process 203. It is.

  When an exception occurs during the execution of the program by the method execution unit 118, it is determined which area the exception has occurred by referring to (step 1501). If the area where the exception occurred is the reference route 114, the reference route 114 has not yet been switched to the Java heap area (new) 112 of the reference route 114 by the area switching processing 203. The guard area is released (step 1502), and the destination indicated by the reference route 114 is switched from the Java heap area (old) 111 to the Java heap area (new) 112 (step 1503).

  If the area supplemented with the exception is the Java heap area (old) 111, the reference route 114 remains pointing to the Java heap area (old) 111, so change it to point to the Java heap area (new) 112. (Step 1503). Also, if the area where the exception occurred is the Java heap area (new) 112, it is before the contents updated in the Java heap area (old) 111 by the Java heap area (old) update contents reflection process 204 are reflected, Only the thread assigned from the thread mechanism 126 to the method execution unit 118 that generated the exception is stopped by the thread control unit 125 (step 1504). The stopped thread is resumed in step 1308 of the Java heap area (old) update content reflection process 204.

  As described above, according to this embodiment, the GC process can be performed in parallel with the execution of the program, and the contents of the data in the Java heap area updated by the execution of the program during the GC process are displayed in the GC. It is possible to reflect the result at the end of processing.

It is a block diagram which shows the structure and input / output data of a computer system with which JavaVM of this embodiment operates. It is a flowchart which shows the method of reducing the stop of all the threads in JavaVM of this embodiment. FIG. 5 is a timing diagram showing timings at which each process is performed in the Java VM of the present embodiment. It is a figure which shows the data structure of an update management table in JavaVM of this embodiment. It is a figure which shows the data structure of a movement offset table in JavaVM of this embodiment. It is a flowchart which shows the procedure which copies a Java heap area in JavaVM of this embodiment. It is a figure which shows the copy of the reference data and the data of an object in JavaVM of this embodiment. It is a flowchart which shows the procedure which performs GC processing with respect to the copied Java heap area in JavaVM of this embodiment. 6 is a flowchart illustrating a procedure for switching a reference route that refers to a Java heap area before copying to a Java heap area that is a copy destination in the JavaVM of the present embodiment. It is a figure which shows the guard area | region for detecting the unauthorized reference with respect to the updated object in Java heap area | region (new) in JavaVM of this embodiment. In JavaVM of this embodiment, it is a figure which shows the dummy object produced | generated to the Java heap area (new) corresponding to the object produced | generated to the Java heap area (old) after the Java heap area copy process. In JavaVM of this embodiment, it is a figure which shows the guard area | region for detecting that the reference route was used before changing the pointing destination of a reference route to a Java heap area | region (new). In JavaVM of this embodiment, before switching the program execution to the copy-destination Java heap area, show the procedure for reflecting the update contents made in the Java heap area before the copy by executing the program to the copy-destination Java heap area It is a flowchart. In the JavaVM of this embodiment, before switching the program execution to the copy destination Java heap area, it is a flowchart showing a procedure for recording that the update is performed in the Java heap area before copying by executing the program. 6 is a flowchart illustrating a procedure for preventing an illegality when a Java heap area becomes invalid due to execution of a program in the JavaVM of the present embodiment.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 101 ... Computer system, 102 ... Auxiliary storage device, 103 ... Java class file, 104 ... Java source file, 105 ... Main memory, 106 ... Java compiler, 107 ... JavaVM, 108 ... Method reading part, 109 ... Data area, 110 ... Java heap area, 111 ... Java heap area (old), 112 ... Java heap area (new), 113 ... method information, 114 ... reference route, 115 ... moving offset table, 116 ... update management table, 117 ... update table management unit 118 ... Method execution unit, 119 ... Exception processing unit, 120 ... Java heap management unit, 121 ... GC execution unit, 122 ... Java heap copy unit, 123 ... Copy unit, 124 ... Reference management unit, 125 ... Thread control unit, 126 ... Thread mechanism, 127 ... Operating system, 128 ... Bus, 129 ... Output device, 130 ... Central processing unit, 131 ... Input device

Claims (5)

In a garbage collection method in a computer system that performs garbage collection of an object stored in a storage device,
The contents of the first heap area in the storage device in which the computer system stores objects that can be referenced or updated by a program are stored in the second heap area in the storage device, and the computer system is garbage collected. The information in the storage device indicating the heap area is changed from the contents indicating the first heap area to the contents indicating the second heap area, and the computer system executes garbage collection in the second heap area. The program is continuously executed during execution of garbage collection in the second heap area. After execution of garbage collection in the second heap area, the computer system refers to an object by the program. Whether the information in the storage device indicating the reference route is the first heap area Garbage collection method characterized by changing the contents to refer to the second heap.   The computer system is updated in the first heap area before reflecting the contents of the object updated in the first heap area in the storage device to the second heap area in the storage device. 2. The garbage collection method according to claim 1, wherein when the program attempts to refer to an object in the second heap area corresponding to the object, it detects that the reference is attempted.   The garbage collection method according to claim 2, wherein the computer system stops only a thread of a program that tried to perform the detected reference. In a computer system that performs garbage collection of objects stored in a storage device,
A copy unit that stores the contents of a first heap area in a storage device that stores objects that can be referenced or updated by a program in a second heap area in the storage device, and a storage device that indicates a heap area in which garbage collection is performed A thread control unit for changing the information in the content indicating the first heap area from the content indicating the second heap area, and a garbage collection executing part for executing garbage collection in the second heap area, A thread execution unit that continuously executes the program even during execution of garbage collection in the second heap area; and after executing garbage collection in the second heap area, when the object is referred to by the program The information in the storage device indicating the reference route is obtained from the first heap area. Computer system, characterized in that it comprises a reference management unit for changing the contents to refer to the second heap. In a program for causing a computer to execute a garbage collection method in a computer system that performs garbage collection of objects stored in a storage device,
The contents of the first heap area in the storage device in which the computer system stores objects that can be referenced or updated by a program are stored in the second heap area in the storage device, and the computer system is garbage collected. The information in the storage device indicating the heap area is changed from the contents indicating the first heap area to the contents indicating the second heap area, and the computer system executes garbage collection in the second heap area. The program is continuously executed during execution of garbage collection in the second heap area. After execution of garbage collection in the second heap area, the computer system refers to an object by the program. Whether the information in the storage device indicating the reference route is the first heap area A program characterized by executing the garbage collection process to change the contents to refer to the second heap area computer.

Images