The present invention relates to a memory management technique in a computer program.
In developing a computer program, it is known that paying attention to processes for securing a memory area to be used when executing a program and for deallocating the memory area is a burden for a programmer and would cause errors (or defect) in programming. For example, in the C/C++ language, which is a typical language, the user needs to explicitly describe the securing and reclamation required to execute a program, and program defects are frequently caused by this.
As examples of the program defect, a memory leak caused by forgetting to deallocate a secured memory area, and an illegal reference to a deallocated memory area (that data to be originally referenced does not exist in a reference destination) can be mentioned. The program developer must develop a program while always paying attention to the utilization states of memories. Because of program development conducted by a plurality of persons and enlargement of program codes, however, it is becoming difficult to describe the securing and reclamation of all memories accurately.
As means for solving this, utilization of a garbage collector, which automatizes memory arrangement in a program, can be mentioned. In Java (trademark), which is one of language processing systems for conducting memory management by utilizing a garbage collector, an API (Application Program Interface) for memory securing at the time of program execution is prepared. However, an API for deallocation does not exist. Deallocation of a memory area secured in the process of program execution is conducted by a garbage collector mounted on a Java virtual machine, which executes a Java program. Garbage collection (hereafter referred to as “GC” as well) executed by the garbage collector frequently assumes an implementation form in which all Java program execution threads are stopped and unnecessary data are withdrawn.
The time when the Java virtual machine starts GC is immediately before the use quantity of a Java heap memory, which stores data (Java object) generated on the Java program, exceeds a certain threshold. However, it is difficult for the user to estimate the memory use quantity required for program execution, and it is also difficult to foresee the timing of exceeding the threshold. Therefore, it is also difficult for the user to foresee the start of GC in response to exceeding the threshold. As a result, the program in execution stops at irregular intervals.
In generational garbage collection, which is often adopted as the GC implementation scheme in the Java virtual machine, the scenarios of GC that needs a short time for stopping Java program execution threads and GC that needs a long time for stopping Java program execution threads may occur. However, it is difficult to foresee which of the GCs occurs the next time. In recent years, Java systems have begun to' be used on the server sides and built-in fields (such as industrial devices and home electric appliances). However, it has become regarded as a problem that the response of the whole system disappears if a long time program stop is caused by unexpected GC.
Methods for solving this problem are disclosed in, for example, F. Pizlo, J. M. Fox, D. Holmes and J. Vitek, “Real-Time Java Scoped Memory: Design Patterns and Semantics,” Proceedings of the Seventh IEEE Internal Symposium on Object-Oriented Real-Time Distributed Computing, 2004, and Masahiko Adachi, Motoki Obata, Hiroyasu Nishiyama, Koichi Okada, Kei Nakajima, “Evaluation of Java Virtual Machine with Explicitly Managed Heap Memory,” Seventh IEEE Forum on Information Technology (FIT 2008), 2008. In the methods disclosed in these documents, a non-garbage collected heap memory (hereafter referred to “external heap memory”) is included besides a garbage collected heap memory subjected to garbage collection conducted by the Java virtual machine (hereafter referred to as “Java heap memory”). The external heap memory is a memory area that can be subjected to memory management by the program. In other words, securing of the external heap memory, generation of an object and deallocation of the external heap memory follow description in the source code in the program generated by the programmer.
In reclamation of the external heap memory area according to the technique disclosed in the Pizlo's document, a restriction is placed on the reference relation of data generated in a secured memory area in order to deallocate the memory area with a low overhead. This restriction aims at ensuring that program execution is not influenced even if the area is deallocated together with data at the time when any thread for generating data has not been left in the external heap memory. In this way, occurrence of a long time stop of the Java program execution thread is suppressed by using an area that can be subjected to memory area management conducted by the program, i.e., the external heap memory, which is non-garbage collected heap memory, and that is not subjected to garbage collection conducted by the Java virtual machine, and placing a restriction on the reference relation of data. However, this restriction item hampers the convenience of the external heap memory remarkably.
Because of the restriction on the reference relation between data, it is necessary for the user to conduct programming while always paying attention to the reference relation between data. However, it can be said that it is extremely difficult to completely grasp the reference relation on the memory because of the enlargement of the program scale or occurrence of implicit data generation, which is not described on the user program (data generation conducted by a program that is not described by the user). If a reference relation violating the restriction has occurred as a result of a check at the time of execution concerning the restriction item, then “exception” occurs and the program is not executed normally in many cases. In addition, it is also a problem that remarkable performance degradation is caused by the check processing as compared with the execution performance of the program in the case where the external heap memory is not used.
According to the technique disclosed in the Adachi's document, it is made possible to utilize the external heap memory area without placing a restriction on a reference relation between objects, in order to cope with the above-described problems. The restriction item on the reference relation in the technique disclosed in the Pizlo's document aims at conducting deallocation of the external heap memory area safely. On the other hand, according to the technique disclosed in the Adachi's document, when deallocating the external heap memory area, a reference relation between data in a memory area to be deallocated and data in a memory area to be not deallocated is examined and data in the memory area to be deallocated that is required for later execution is moved to the memory area to be not deallocated. After it is thus ensured that deallocation of the memory area to be deallocated will not constitute a hindrance to execution of the program, the memory area to be deallocated is deallocated. As a result, the API for external heap memory can be utilized without worrying about the reference relation between data. In addition, since the investigation of the reference relation is conducted only at the time of deallocation of the memory area, the check is not necessary at the time of execution concerning the restriction item.
FIG. 13 is a diagram showing a program to be used when utilizing the external heap memory in the API. The program shown in FIG. 13 is an example that generates data in the List class and makes it possible to reference data of and o2 in Object class from the data in the List class. In the original program, the “new” operator is used to generate data in the List class as in an executable statement shown in a line 1301 provided with a comment. In order to utilize the external heap memory, however, a change to executable statements as shown in lines 1302 and 1303 is made.
The line 1302 is an executable statement for ordering generation of an external memory. Here, data in the ReferenceExplicitMemory class is generated, and a non-garbage collected external heap memory is generated. In an executable statement indicated in the next line 1303, data in the List class is generated for the generated external heap memory. Furthermore, an executable statement for an order of deallocation (deletion) of the generated external heap memory is indicated in a line 1304. If the executable statement indicated in the line 1304 is executed, then the external heap memory generated by the executable statement indicated in the line 1302 is deallocated. If at that time there is a reference to data in the external heap memory from an area other than the external heap memory to be deallocated, then reclamation is conducted after the data group that is being referenced is moved to a memory that is not to be deallocated.
There are two kinds in the method for disposing data into the external heap memory. One of them is a method for disposing all data generated in a certain section in the external heap memory, and the other is a method for disposing only data that can be referenced from among data associated with the external heap memory (associated for arrangement) in the external heap memory. A description for utilizing an external heap memory of a type in which data is disposed by utilizing the latter cited reference relation is shown in FIG. 13. The data generation statement for the external heap memory indicated in the line 1303 is regarded as association with the external heap memory generated by the executable statement indicated in the line 1302.
FIG. 17 is a diagram showing an image of memories and data immediately before executing an executable statement indicated by a line 1305 in FIG. 13. Data li (reference numeral 1701) in the List class generated by the executable statement indicated in the line 1303 is disposed in the external heap memory 112 which is generated by the executable statement indicated in the line 1302. Data o1 (reference numeral 1702) and o2 (reference numeral 1703) in the Obj class are generated in the Java heap memory 111. As other data, data E (reference numeral 1704-1) and F (1704-2) are also disposed in the Java heap memory 111. An arrow 1705 between data represents a reference relation between data. If the executable statement indicated in the line 1305 in FIG. 13 is executed in this state, then it becomes possible to reference the data o1 (reference numeral 1702) and o2 (reference numeral 1703) from the data li (reference numeral 1701) associated with the external heap memory 112. This state is shown in FIG. 18.
In FIG. 18, references to the data o1 (the reference numeral 1702) and o2 (the reference numeral 1703) from the data li (the reference numeral 1701) are indicated by arrows 1801 and 1802, respectively. Thereafter, the data o1 (the reference numeral 1702) and o2 (the reference numeral 1703) are moved to the external heap memory 112 in response to a certain opportunity. As the certain opportunity, garbage collection or an excess of the memory use quantity over a threshold is considerable. An image of the data o1 and o2 after the movement is shown in FIG. 19. The data o1 and o2 that can be referenced from the data li (the reference numeral 1701) associated with the external heap memory 112 are moved into the external heap memory 112 as represented by reference numerals 1901 and 1902, respectively. It is now supposed that the executable statement for deallocating the external heap memory 112 indicated in the line 1304 is executed. If the external heap memory 112 is deallocated in the state shown in FIG. 19 and its internal data are deleted, then a reference to the data o2 (the reference numeral 1902) from the data F (reference numeral 1704-2) becomes illegal and the later execution result cannot be ensured.
If there is a reference to the external heap memory 112 (the memory that is to be deallocated) from the Java heap memory (the memory that is not to be deallocated) as represented by an arrow 1707, therefore, the referenced data o2 (the reference numeral 1902) in the external heap memory 112 (the memory that is to be deallocated) is moved (copied) into the Java heap memory (the memory that is not to be deallocated). The state after the movement (copy) is shown in FIG. 20. In FIG. 20, the data o2 (the reference numeral 1902) is moved (copied) to data o2′ (reference numeral 2001), and the arrow 1707, which indicates the reference from the data F (the reference numeral 1704-2), is also changed to a new arrow 2002. Since the data o2 (the reference numeral 1902) and the data o2′ (reference numeral 2001) are the same data, a reference to the data o2′ (the reference numeral 2001) from the data F (the reference numeral 1704-2) is similar to the reference to the original data o2 (the reference numeral 1902) from the data F (the reference numeral 1704-2). It can be ensured that there is no influence upon the result of later execution even if the data li (the reference numeral 1701), o1 (the reference numeral 1901) and o2 (the reference numeral 1902) are deleted together with the external heap memory 112.