JP5564540B2 - Memory management method, computer and program - Google Patents

Description

  The present invention relates to a memory management method in a computer, the computer, and a program.

  When developing a computer program, securing and releasing the memory area used by the program is one of the items that bother the program developer and is known to be prone to program failures. Yes. For example, in the C / C ++ language, which is a general programming language, the user must explicitly describe the allocation and release processing of the memory area required for program execution, resulting in frequent program failures. Yes. Examples of program failures include memory leaks that occur when you forget to collect (delete) data in an allocated memory area (a phenomenon where the available memory area gradually decreases against the intention of the program creator) or has been released An illegal reference to the memory area is given. The program developer must develop the program while always paying attention to the state of memory usage. However, the program development by multiple people and the enlargement of the program code ensure a complete grasp of all memory allocation / release processes. It is becoming difficult to do.

  As a means for solving this, use of a garbage collector for automating memory management in a program can be mentioned. Java (Java is a trademark of Sun Microsystem, Inc., USA), one of the language processors that manage memory using a garbage collector, has an API (Application Program Interface) for securing memory during program execution. Is provided, but there is no release API. That is, a Java program (hereinafter, simply referred to as a program) developer needs to clearly indicate the allocation of the memory area, but does not need to describe the process for releasing the allocated memory area. The memory area secured in the process of program execution is released by the garbage collector implemented in the Java virtual machine that executes the program. The function executed by the garbage collector is garbage collection (hereinafter referred to as GC). In other words, the GC is a function of collecting unnecessary data from the memory area dynamically allocated by the program and automatically releasing the area.

  Depending on the implementation method, GC basically stops all Java program execution threads and collects unnecessary data. The Java virtual machine starts the GC (executes a garbage collector having a GC function), which stores the data (object) generated in the program (sometimes referred to simply as generation) in the Java heap memory. When the usage exceeds a certain threshold. It is difficult for the user to estimate the amount of memory used by program execution, and it is also difficult to predict when the threshold will be exceeded. Therefore, since it is difficult for the user to foresee the start of the GC due to exceeding this threshold, the execution of the program is stopped irregularly by the start of the GC. Furthermore, generational garbage collection, which is often adopted as a GC implementation method in the Java virtual machine, generates a GC that finishes in a short time and a GC that requires a long stop. It is difficult to predict what will happen. If it can be predicted that a GC that stops for a long time will occur, it is possible to avoid an unexpected long stop by explicitly generating a GC when the load on the execution environment (Java virtual machine) is low. It is unclear to the user when the time-consuming GC occurs as described above.

  In recent years, Java systems (systems that execute programs written in the Java language on a Java virtual machine) have come to be used in embedded fields such as servers, mobile phones, and car navigation systems. However, in these fields, when a program stop due to unexpected GC startup occurs, there is a problem that the response of the entire system is lost, and a method for solving this has been developed [Non-Patent Document 1], [Non-Patent Document 1] Patent Document 2].

  In order to avoid program stoppage due to GC, for example, in the Java specification Real Time Specification for Java (hereinafter RTSJ) specialized for real-time processing, an external memory area that is not subject to GC can be set as Scoped Memory. Data generated by a series of program processing is generated not in the Java heap memory that is the target of GC, but in Scoped Memory that is explicitly secured by the program, making it difficult for GC to occur due to depletion of Java heap memory ing. After a series of program processing, the data generated in Scoped Memory is no longer necessary. However, instead of collecting unnecessary data with GC, it is deleted for each Scoped Memory (data is deleted and secured as an available area) Rather than deleting the area, if you want to use the area, reserve the area again). Hereinafter, such deletion of the memory area is referred to as “release”.

  Whatever memory management method is used, data necessary for executing the program must remain in the memory. In the memory management method using the garbage collector, all the data that can be referred to from the location called the root set, such as registers and runtime stacks, is handled as the data necessary for execution, and the data necessary for the subsequent execution of the program is unnecessary. The correct data.

  On the other hand, when using a GC avoidance technique such as RTSJ that sets a memory area that is not subject to GC, a certain restriction is imposed on the programming API so that the execution result of the program will not be invalid. Overhead checking occurs. Here, the “constant constraint” is a constraint for Scoped Memory existence or a limitation of reference between data. Scoped Memory in RTSJ is only when one or more threads generated by a Java program are executing the scope indicated by the enter method or executeInArea method, that is, during a certain section (from a predetermined step of the program to another predetermined step) It is a memory area that can exist, and is automatically released when all threads leave this scope. Therefore, in order for Scoped Memory to survive, one or more threads must be executing this scope, which is positioned as a temporary data area.

  In the ScopedMemory release processing, the data in the Scoped Memory is released without performing any processing, but in order to realize this, the reference relationship regarding the data generated in the scope is limited [Non-patent document 1] [Non-patent document] 2].

  The memory area and data arrangement shown in FIG. 11 (a) will be described as an example. In FIG. 11A, there are data 1102-1 and 1102-2 on the Java heap memory 110 that is the target of the GC, and data 1103-1 and 1103-2 on the scoped memory 1101 that is reserved as a target of the GC. Data 1102-1 and data 1103-2 refer to data 1103-1, and data 1103-2 refers to data 1102-2. This is an invalid memory state for RTSJ. In FIG. 11A, the reference from the data 1102-1 to the data 1103-1 is indicated by the arrow 1104, the reference from the data 1103-2 to the data 1103-1 is indicated by the arrow 1105-1, and the reference from the data 1103-2 to the data 1102- Reference to 2 is indicated by arrow 1105-2. If this scoped memory 1101 is released together with the internal data 1103-1 and 1103-2, the memory area and the state of the data are as shown in FIG.

  As shown in FIG. 11 (b), the reference destination of the data 1102-1 is an illegal memory area that has already been released, and even if the program execution is continued in this state, it does not operate correctly. RTSJ introduces a stack concept called scope stack to prevent this situation. In the scope stack, there is a restriction that data generated in a shallow scope cannot be referenced from data generated in a deep scope, so that a reference such as reference 1104 in Fig. 11 (a) cannot be generated in the first place. I have to. (Thus, FIG. 11 (a) is an invalid state.) According to this restriction, when there is no thread that executes a scope that generates data for a certain scoped memory, this scoped memory is lost. It can be assured that releasing the program does not affect the execution of the program.

  For example, in FIG. 11A, if execution of a scope in which data (1102-1 and 1102-2) is first generated on the Java heap memory is started, this information is stored in the scope stack. After that, when Scoped Memory is created and one or more threads start executing the scope section specified by the enter method and executeInArea method for the Scoped Memory, this scope information is added to the scope stack. Assuming At this point, the scope stack stores information called “Scope that generates data in Java heap memory” at a deep position in the stack, and information called “Scope that generates data in Scoped Memory” at a shallow position. Will be.

  In light of the restrictions on the reference relationship between data in RTSJ, references to data 1102-1 to data 1103-1 in Figure 11 (a) are shallower than the data generated by the scope that is deeper in the scope stack. Since it is a reference to data generated in a certain scope, it cannot be generated. On the other hand, the reference 1105-1 from the data 1103-2 to the data 1103-1 and the reference 1105-2 to the data 1102-2 in FIG. 11 (a) are the data generated by the scope at a shallow position on the scope stack. Since it is a reference to data generated in a deep scope, it can be generated. When all threads leave the scope that generates data for this scoped memory, it becomes impossible to refer to the data in the scoped memory, so even if this memory area is released, program execution will be affected. There is nothing.

Angelo Corsaro and Ron K. Cytron, Efficient Memory-Reference Checks for Real-time Java, Proceedings of the 2003 Conference on Languages, Compilers, and Tools for Embedded Systems, 2003. 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.

  In a system such as a Java system that manages memory by garbage collection, when a memory area that is not subject to garbage collection and can be explicitly secured from a program can be used, the data between the memory area's survival and use The restrictions on the reference relationship of the above significantly impair the convenience of this memory area. In other words, as a condition for the memory that has been explicitly secured from the program to exist, one or more threads must be running in the interval for generating data for that memory area. Imposing. In addition, due to the restriction of the reference relationship between data, the user must always program while paying attention to the reference relationship between data. However, the program size is enlarged and implicit data generation that is not described in the user program Due to the occurrence of this, it is extremely difficult to completely grasp the reference relationship in the memory area. When a reference relationship that violates this restriction occurs due to a check at the time of execution, exception handling (Exception) occurs and the program may not be executed normally.

  Another problem is that due to the execution check related to the above restrictions, a significant performance drop occurs with respect to the execution performance of the program when such a memory area is not used.

  In the description of the present invention and the embodiment, the meaning of “release” of a memory area (also simply referred to as memory or area) will be clarified. The release of the memory area is to prevent a program from recognizing an area of a predetermined capacity secured at a predetermined position on the memory or data in the area. Therefore, access from the program to the memory area after release is illegal (access). If a new memory area is required after the memory area is released, a new memory area is generated (secured). In response to the release of the memory area, data stored in a predetermined capacity area secured at a predetermined position on the memory may be collected and used as a storage location for new data. This data collection function is garbage collection.

  In one aspect of the present invention, a memory area is secured by a program executed by a processor in a computer, and data is stored in the secured memory area in accordance with execution of the program. In response to an instruction to release the secured memory area by the program, it is checked whether data necessary for subsequent execution of the program exists in the memory area instructed to be released. This is a memory management method for releasing a memory area instructed to be released when data (object) necessary for subsequent execution of the program does not exist in the memory area instructed to be released as a result of the check.

  Another aspect of the present invention is a computer having a memory and a processor, and is configured as follows. The memory is provided with a first area managed by garbage collection and a second area that is secured, stores data, and is released according to the execution of the program. In response to an instruction to release the second area accompanying the execution of the program, the processor moves the data to the first area when data necessary for subsequent execution of the program exists in the second area. .

  According to the present invention, a memory area secured by a program can be released without restricting the execution of the program.

It is a structural example of the computer of an Example. It is an example of a program that generates, uses (data generation), and releases an external heap memory. This is an example of generating and moving data to an external heap memory. This is an example of collecting unnecessary data on the external heap memory. This is an example of specifying an opportunity to move data to the external heap memory. It is an example of a state of releasing the external heap memory. External heap memory release processing. It is an example of a state of releasing the external heap memory. This is an example of instructing to generate an exception when necessary data remains when the external heap memory is released. This is the release process when the operation when the necessary data remains when the external heap memory is released is specified. This is an example of generating data to Scoped Memory.

  In the best mode for carrying out the present invention, a memory area is secured by a program executed by a processor, and data is stored (an object is generated) in the secured memory area in accordance with the execution of the program. In response to an instruction to release the secured memory area by the program, it is checked whether data necessary for subsequent execution of the program exists in the memory area instructed to be released. As a result of the check, when the data (object) necessary for the subsequent execution of the program does not exist in the memory area instructed to be released, the memory area instructed to be released is released.

  As a result of the check, when data necessary for subsequent execution of the program exists in the memory area instructed to be released, the data is moved to a memory area different from the memory area instructed to be released. Data necessary for program execution is moved to a memory area different from the memory area, and garbage collection is executed in the different memory area.

  Another aspect of the present invention is a computer having a memory and a processor, and is configured as follows. The memory is provided with a first area managed by garbage collection and a second area that is secured, stores data, and is released according to the execution of the program. In response to an instruction to release the second area accompanying the execution of the program, the processor moves the data to the first area when data necessary for subsequent execution of the program exists in the second area. . Thereby, it is possible to realize a computer that does not cause a decrease in the execution performance of the program.

  An embodiment of a memory management method according to the present invention will be described with reference to the drawings. Although this embodiment is described for a Java system (a system in which a program written in the Java language is executed on a Java virtual machine (also referred to as an execution environment)), other systems having a garbage collection function are described. Is also effective.

  FIG. 1 is a diagram illustrating a configuration of a computer 101 according to the present embodiment. The computer 101 includes a processor (CPU) 102 for executing each process, a Java program 104 executed by the Java virtual machine (Java VM) 105 on the processor 102, a Java heap memory 110 used by the Java virtual machine 105, and an external heap memory 111. A memory 103 including −1 to 3 is included. The external heap memory 111 is generated in response to the execution of an external heap memory generation statement described in the Java program 104. Note that the Java program 104 may be stored not in the memory 103 but in the external storage device 112.

  In addition to the required processing, the Java program 104 includes descriptions such as creating an external heap memory, storing data in the external heap memory (generating objects), and releasing the external heap memory. By executing 105, the external heap memory 111 is generated, used, and released. On the other hand, the Java heap memory 110 is subjected to memory management such as garbage collection by the Java virtual machine 105 and cannot be managed from the Java program 104.

  In order to execute the Java program 104, the Java virtual machine 105 reads the Java program 104 by the program reading unit 106, and generates an external heap memory 111 by the external heap generation unit 107 when a statement for generating the external heap memory 111 is executed. In the data generation section for the external heap memory 111 described in the Java program 104 (from a predetermined step to another predetermined step), data is generated in the external heap memory 111 by the data generation unit for the external heap memory 111. To do. In addition, when the release of the external heap memory 111 is explicitly instructed on the Java program 104, the external heap release unit 109 causes the data on the external heap memory 111 among the data necessary for execution to be excluded from the release target memory. After moving to the area, the external heap memory 111 is released.

  FIG. 2 shows an example of the Java program 104 including descriptions for generating the external heap memory 111, generating data in the external heap memory 111, and releasing the external heap memory 111. The numbers on the left of each line in FIG. 2 are line numbers and are not described in the actual program. The statement 201 on the second line is a description for generating (allocating) the external heap memory 111. The data generated in the process 202 from the enter method on the fourth line to the exit method on the sixth line is stored in the external memory 111. It can be generated (stored) directly, or first generated on the Java heap memory 110 and explicitly moved to the external memory 111 with the commitChanges method in the statement 204 on the eighth line. Here, the section is from the 4th line to the 6th line. If data is generated directly in the external heap memory 111 during the processing 202 in this section, all of the data is generated in the external heap memory 111 during the processing 202. Therefore, unnecessary data is immediately stored in the external heap memory 111. As a result, the use efficiency of the memory area of the external heap memory 111 is deteriorated. On the other hand, by generating the data in the Java heap memory 110 and then moving the necessary data to the external heap memory 111, it is a countermeasure against deterioration in the use efficiency of the memory area.

  The commitChanges method for instructing movement of data to the external heap memory 111 on the program can specify not only the instance of the movement target memory as an argument but also the data to be moved. In the example of FIG. 2, since only the external heap memory em to be moved is specified, all of the data to be moved to the heap memory em is moved. Incidentally, the data generated in the other part (outside the section 202) is generated on the Java heap memory 110. As shown on the 9th line in FIG. 2, after the data generated on the external heap memory 111 is used for arbitrary processing and the data on the external heap memory 111 becomes unnecessary, 11 in FIG. Instructs the release of the external heap memory em as in statement 203 on the line. When using the external heap memory em in the arbitrary process on the 9th line in FIG. 2, there are no restrictions on the program or investigation of the reference relationship at the time of execution.

  FIG. 3, FIG. 4, and FIG. 5 show other program examples. Figure 3 shows the moveObject method that moves existing data (object) to the external heap memory em as shown in the statement 301 on the 4th line, instead of instructing data generation to the external heap memory 111 with the enter / exit method. Alternatively, as shown in the statement 302 on the sixth line, the external heap memory em is used by using the newInstance method that specifies the class of data to be generated and generates data directly in the external heap memory em.

  Further, as shown in a sentence 401 in FIG. 4, a compact method for instructing collection of unnecessary data (objects) in the external heap memory em can be executed to increase the free space in the external heap memory em.

  If you want to move more data to the external heap memory em in the arbitrary process shown on the 12th line in Fig. 4, the amount of data that can be moved by executing the compact method shown in the sentence 401 on the 11th line in advance Can be increased.

  Figure 5 shows that the data generated in the process 501 is not generated in the Java heap memory 110 by giving CommitMode.MOVE_ON_GC as an argument of the enter method instead of explicitly indicating the data movement with the commitChanges method. This is an example of moving to the external heap memory em as an opportunity. Since the data in the Java heap memory 110 is determined to be data necessary for the subsequent execution of the program and the data generated in the process 501 moves to the external heap memory em, unnecessary data moves. The external memory area em can be used effectively.

  The release process of the external heap memory 111 is executed by the external heap release unit 109 in FIG. At this time, the case where the data on the external heap memory 111 is necessary for the execution of the Java program 104 must be considered. For example, the data arrangement on the memory 103 as shown in FIG. 6A shows data 601-1 and 601-2 on the Java heap memory 110, data 602-1 and 602-2 on the external heap memory 111, and data 601-1 and data 602-2. 602-1 and data 602-2 refer to data 601-2. In FIG. 6A, the reference from the data 601-1 to the data 602-1 is indicated by the arrow 603, the reference from the data 602-2 to the data 602-1 is indicated by the arrow 604-1, and the reference from the data 602-2 to the data 601-2. Reference to 2 is indicated by arrow 604-2. When the external memory 111 is released from this state, the data 602-1 and 602-2 on this memory are deleted, and even if the references 604-1 and 604-2 that are references from the data 602-2 disappear, Java There is no problem in executing the program 104. However, for the reference 603, as shown in FIG. 6B, the data referred to by the data 601-1 refers to an invalid memory area, and the Java program 104 does not operate correctly.

  In such a case, there is a method of executing exception processing (processing executed in response to an error when an error that is not originally assumed in the program occurs) that the processing of the Java program 104 cannot be continued. However, if you want to continue the Java program 104 normally, move the data 602-1 onto the Java heap memory 110 that is not the release target before releasing the external heap memory 111 that is the release target, and change the reference relationship between the data. By correcting, the Java program 104 can be correctly executed even after the external heap memory 111 is released.

  FIG. 7 shows the processing of the external heap release unit 109 including processing that guarantees normal execution of the Java program 104. In process 701, the presence / absence of reference from the data in the memory area not to be released to the data in the memory area to be released is checked. In process 702, the presence or absence is determined. If there is a reference, the reference destination data is moved to a non-release target memory in process 703. At that time, the reference from other data to the movement source to the moved data is corrected to the movement destination. In process 704, the data referred to by the data moved in process 703 is examined. In process 705, it is determined whether or not the reference destination data is in the release target memory. The processing is executed from processing 703 as data. On the other hand, if the memory outside the release target memory is being referred to, the process returns to the process 701 and the investigation of the reference to the data in the release target memory area is continued.

  Even if the process 701 is applied to all the data in the non-release target memory area, if no reference to the data in the release target memory is found, the process proceeds from the process 702 to the process 706 to release the target memory. Here, there may be a plurality of release target memory areas. In this case, after executing the processes 701 to 705, a plurality of areas are released at a time in the process 706. The reference relationship from the data in the memory not to be released to the data in the memory to be released checked in the process 701 is the data between the data pointed from the location called the GC root in order to detect the data necessary for program execution in the GC. May be part of a reference relationship. Therefore, if the data that can be referred to in this reference relationship is moved to the non-release target memory area, it is guaranteed that the data judged to be necessary for execution in the GC is at least moved. Even after release, program execution can continue safely.

  When the release processing shown in Fig. 7 is applied to Fig. 8 (a), reference is first made from data 801-1 on non-release target memory (Java heap) 110 to data 802-1 on release target memory (external heap) 111 803 is found. Therefore, in the process 703, the data 802-1 is moved to the non-release target memory 110 to be the data 806, and the reference 803 from the data 801-1 is corrected as indicated by the reference 807. Since the data 802-1 becomes the data 806, a reference 808 is newly generated. FIG. 8B shows the data arrangement on the memory after this processing 703.

  Next, when the data referenced from the movement source data 802-1 of the data moved in the process 703 is examined in the process 704, the existence of the data 802-2 can be found by following the reference 804. In processing 705, if the location of the data 802-2 is confirmed, it is found that it is in the release target memory 111, so the target data is changed to 802-2, and processing 703 is executed. FIG. 8C shows a state after the second processing 703, data 802-2 is moved to data 809, and reference 808 from data 806 to data 802-2 in FIG. Reference 810 has been modified. Further, the reference 805 from the data 802-2 to the data 801-2 in FIG. 8B becomes the reference 811 because the data 802-2 has moved to 809.

  In the state of FIG. 8C, the processes 704 and 705 are executed again. However, since the data 801-2 referenced from the data 802-2 is in the non-release target memory 110, the process returns to the process 701. Since the reference to the release target memory cannot be found in the second process 701, the process proceeds from process 702 to process 706 to release the external heap memory 111. As shown in FIG. 8 (c), since there is no reference to the external heap memory 111, there is no problem in executing the program even if the memory area 111 is released. In addition, for 805 representing the reference from the data 802-2 to the data 801-2, the reference source data 802-2 is not referenced from the data in the memory not to be released, so its presence affects the subsequent execution of the Java program. Will not affect.

  In the process of releasing a memory area explicitly secured by a program, if there is data necessary for execution in the memory to be released, it is possible to execute exception processing instead of moving the data necessary for execution. . In this case, exception processing can always be executed when it is discovered that data necessary for execution remains, and the operation at the time of execution of the reclaim method that explicitly indicates area release is shown in the sentence 901 of FIG. It can also be specified like the setReclamationAction method. The statement 901 instructs to generate an exception when data necessary for execution remains in the release area when the area is released. In addition to “EXCEPTION” that generates an exception, “MOVE_TO_JAVA_HEAP” that moves data required for execution to the Java heap memory can be described in the argument of the setReclamationAction method.

  FIG. 10 shows the area release processing when setReclamationAction can be used. In process 701, the presence or absence of reference to the data in the release target memory area is checked from the data in the non-release target memory area, and if there exists, the process moves from process 702 to process 1001. In process 1001, the process set by the setReclamationAction method is examined, and if EXCEPTION is specified, an exception is issued in process 1002, otherwise it is instructed to move necessary data to the Java heap memory 110 In this case, the processing shifts to processing 703 in FIG. If there is no reference, the memory to be released is released in process 706.

  With the above processing, the generation, use, and release of the external heap memory 111 can be executed safely without restriction of description on the Java program.

DESCRIPTION OF SYMBOLS 101 ... Computer, 102 ... Processor, 103 ... Memory, 104 ... Java program, 105 ... Java virtual machine, 106 ... Java program reading part, 107 ... External heap generation part, 108 ... Data generation part to external heap, 109 ... External Heap release unit, 110 ... Java heap memory, 111 ... external heap memory, 112 ... external storage device.

Claims (20)

A memory management method for a computer having a processor and a memory,
A program having at least one thread including an object is executed by the processor in the computer, thereby securing a second memory area in the memory,
Storing the object in a first memory area in response to execution of the program;
Moving the object stored in the first memory area to the second memory area;
In response to an instruction to release the second memory area from the program, it is determined whether or not an object necessary for subsequent execution of the thread exists in the second memory area;
As a result of the determination, if an object necessary for subsequent execution of the thread does not exist in the second memory area, the second memory area is released,
When an object necessary for subsequent execution of the thread is present in the second memory area, an object required for subsequent execution of the thread is excluded from the memory area that is not subject to the release instruction. And a memory management method for releasing the second memory area. The memory management method according to claim 1, comprising:
A memory management method for moving the object stored in the first memory area to the second memory area in response to occurrence of garbage collection in the first memory area.   The memory management method according to claim 1, wherein the memory area that is not the target of the release instruction is a target of garbage collection. A memory management method according to any one of claims 1 to 3, wherein
The memory management method, wherein the memory area not subject to the release instruction includes the first memory area. A memory management method according to any one of claims 1 to 4, comprising:
The memory management method, wherein an object necessary for subsequent execution of the thread is referred to by an object stored in the memory area not subject to the release instruction. A memory management method according to any one of claims 1 to 5,
Memory management in which when the object referred to by the object moved to the memory area not subject to the release instruction is present in the second memory area, the referenced object is also moved to the memory area not subject to the release instruction Method. A memory management method according to any one of claims 1 to 6, comprising:
A memory management method for moving the object existing in the second memory area to the memory area not subject to the release instruction in response to an instruction by the program. A memory that provides a second memory area secured in the computer by a program having at least one thread including an object being executed by a processor in the computer;
A first memory area in which the object is stored in response to execution of the program;
In response to an instruction to release the second memory area by the program, it is checked whether or not an object necessary for subsequent execution of the thread exists in the second memory area;
As a result of the check, when an object necessary for subsequent execution of the thread does not exist in the second memory area, the second memory area is released,
As a result of the check, when an object required for subsequent execution of the thread exists in the second memory area, an object required for subsequent execution of the thread existing in the second memory area is set in the release instruction. A computer having the processor that moves to a non-target memory area and releases the second memory area. 9. The computer of claim 8, wherein the processor is
A computer that moves the object stored in the first memory area to the second memory area in response to occurrence of garbage collection in the first memory area.   10. The computer according to claim 8, wherein the memory area that is not subject to the release instruction is a garbage collection target. A computer according to any one of claims 8 to 10,
The memory area that is not subject to the release instruction includes the first memory area. A computer according to any one of claims 8 to 11, comprising:
An object required for subsequent execution of the thread is referred to by an object stored in the memory area that is not subject to the release instruction. The computer according to any one of claims 8 to 12, wherein the processor is
A computer in which, when an object referred to by an object moved to the memory area not subject to the release instruction is present in the second memory area, the referenced object is also moved to the memory area not subject to the release instruction. The computer according to any one of claims 8 to 13, wherein the processor is
In response to an instruction from the program, the computer moves the object existing in the second memory area to the memory area not subject to the release instruction. A program having at least one thread containing an object,
On the computer,
A first procedure for securing a second memory area in accordance with an instruction of the program;
A second procedure for storing the object in a first memory area in accordance with execution of the program;
A third procedure for moving the object stored in the first memory area to the second memory area;
A fourth procedure for determining whether an object required for subsequent execution of the thread exists in the second memory area in response to an instruction to release the second memory area from the program;
As a result of the determination, if an object necessary for subsequent execution of the thread does not exist in the second memory area, a fifth procedure for releasing the second memory area;
When an object necessary for subsequent execution of the thread is present in the second memory area, an object required for subsequent execution of the thread is excluded from the memory area that is not subject to the release instruction. And a sixth procedure for releasing the second memory area. The program according to claim 15,
A program for executing the third procedure in response to occurrence of garbage collection in the first memory area. The program according to claim 15 or 16 ,
In the sixth procedure, a program that moves an object necessary for subsequent execution of the thread to a memory area that is a target of garbage collection and that is not a target of the release instruction, and releases the second memory area. A program according to any one of claims 15 to 17,
In the sixth procedure, a program for moving an object necessary for subsequent execution of the thread to the memory area that is not subject to the release instruction, including the first memory area, and releasing the second memory area . A program according to any one of claims 15 to 18, comprising:
In the fourth procedure, it is determined whether or not an object referenced from an object stored outside the second memory area exists in the second memory area as an object necessary for subsequent execution of the thread. program. A program according to any one of claims 15 to 19,
In the sixth procedure,
When an object referred to by the object moved to the memory area not subject to the release instruction is present in the second memory area, the referenced object is also moved to the memory area not subject to the release instruction, A program for releasing the second memory area.

Images