KR20030094658A - Method for explicit dynamic memory management in a system based on automatic dynamic memory management by an application program - Google Patents

Abstract

PURPOSE: A method for directly managing a dynamic memory by an application on an automated dynamic memory management based system environment is provided to realize an API(Application Programming Interface) method to directly collect a garbage object on the dynamic memory and a VM(Virtual Machine) supporting the API. CONSTITUTION: The method to collect the object no more used by the application is transferred to the system(220). In case that the system has no function to collect the selected object, the system transfers an exceptional object related to an error to the application and ignores a collection request when the collection of the dynamic memory or the object is definitely requested(211). In case that the collection method executing exceptional object is not transferred to the application, the selected object is definitely collected from the dynamic memory(231-233).

Description

Method for explicit dynamic memory management in a system based on automatic dynamic memory management by an application program

The present invention relates to a method in which an application explicitly manages a dynamic memory of a runtime system in a computer environment, and more particularly, to an application while maintaining a conventional automated object collection method in an automated dynamic memory-based runtime system. It provides a performance improvement in these systems by providing a way to collect objects directly. In addition, the same location version is stored in the object information area of the dynamic memory in which the object is stored and copied to the object reference variable area so that the application compares the location versions of the object when using or accesses the object and permits the use thereof. By doing so, the system is secured.

In computer systems, memory can be largely divided into static memory and dynamic memory, of which dynamic memory can be divided into explicit dynamic memory management and automated dynamic memory management. Examples of explicit dynamic memory management include allocation-related functions such as malloc () and farmalloc () functions in C, and collection functions of the free () function. These are all done explicitly by the programmer. The advantage of this is that it can optimize memory utilization while the programmer has to manage dynamic memory carefully. If not properly managed, it may adversely affect the whole system. Meanwhile, Garbage Collection is mainly used for automated dynamic memory management. The advantage of this technique is that even if the programmer does not care at all about dynamic memory management, the garbage collection algorithm improves the productivity of the program by preserving future objects and automatically collecting unusable objects. There is an advantage. On the other hand, since it considers only the physical phenomena of the program, it is not possible to accurately determine the preservation and collection of any object from the logical execution of the program. In other words, the dynamic memory efficiency cannot reach 100%. Therefore, this paper proposes an explicit dynamic memory management scheme based on automated dynamic memory scheme, that is, a hybrid dynamic memory management scheme.

For example, consider a Java environment that uses automated dynamic memory management. Among many object-oriented programming languages, JAVA is a programming language specifically designed for use in the distributed environment of the Internet. Java can be used to create application programs that run not only on a single computer, but also on distributed client / server environments on the network, so user-written programs can be easily ported over the network. To this end, user-developed application programs are compiled into Java bytecode to run on any platform, such as a server or client with a Java virtual machine installed. The Java virtual machine interprets this bytecode into code that can be executed on the hardware of the runtime system and executes the contents. This means that differences between individual computer platforms, such as the length of instructions, can be recognized and adjusted locally at the exact location where the program is running. That is, once a Java virtual machine is provided on a platform, any Java program called bytecode can run on that platform. Java is therefore designed to allow applications to run on all platforms without having to be rewritten or recompiled for each platform.

Another feature of the Java language is that it automatically performs dynamic memory management on programmer-generated objects. When heap memory, or dynamic memory, is exhausted due to the application's ongoing object creation needs, a subsystem called garbage collector in the virtual machine can identify garbage objects that the application will no longer use. It serves to reduce these to free memory. Here, dynamic memory is an area of dynamic memory that is reserved in advance for use by a program's process to store a variable amount of data that is not known until the program is executed. Allocate it in the heap area.

The garbage collector automatically manages these heaps, which gives the programmer the ability to create secure applications faster without having to worry about dynamic memory management. Because system resources are required, there is a problem that the application response is slow because system resources are wasted.

In addition, such a garbage collector is designed to distinguish between living and garbage objects by tracking the reference relationship between objects, but this is based on a physical phenomenon and does not consider a logical phenomenon. For example, if object A refers to object B, then object B will survive if object A needs to be alive at the time the garbage collector must determine whether the object survives. However, the garbage collector cannot determine by any algorithm in determining whether an A object merely stores a reference to an B object or what operations it can perform in future. Although the garbage collector kept B objects alive, depending on the logical flow of the program, B objects may not use the references they have in A until the application terminates, which wastes system memory resources. This can shorten the performance cycle of the collector, which can lead to problems that slow down the application's response.

Since the collection of explicit dynamic memory or object of application is not supported in the automated dynamic memory based system using garbage collector as above, the proposed method provides a way to support this. Precautions are taken to prevent object collection from breaking the consistency of object references.

Accordingly, an object of the present invention is to implement an application program interface technique and a virtual machine capable of supporting such an interface so that an application programmer can directly collect useless objects in dynamic memory. It is also an object of the present invention to provide an object creation and collection algorithm using a location versioning technique that prevents system instability due to logical mismatch between object reference and object collection.

1 is a configuration diagram showing an application, a virtual machine, and an application program interface relationship.

2 is a general flow diagram of collection of selected objects when an application wishes to collect unused objects.

3 is a flowchart illustrating an algorithm in which a selection object collector collects the selection object.

4 is a view showing a position version is stored.

5 is a view showing a position version is stored in the object variable

* Description of the symbols for the main parts of the drawings *

100: application 150: virtual machine

160: application program interface 170: selector object collector

411: pointer 412: position version

In order to achieve the above object, the present invention provides a Java virtual machine with a class written in pure Java in order to support a function in which an application directly collects objects in a system dynamic memory in which the application is executed in real time. A selection object collector having a function of collecting objects requested to be collected by an application, and an application program interface providing an interface for collecting an object between the virtual machine and the application.

In addition, if there is an object reference variable (B) referring to an object (A) and another object reference variable (C) referring to A, the object (A) referenced by B is collected. In order to prevent the inconsistency of references, which can occur when an object already collected using an object reference variable C can be accessed, the position version technique is applied. That is, by storing the same location version in the object information area of the dynamic memory where the object reference variable area and the actual object contents are stored, it is determined whether the two location versions are the same when the application later attempts to access the object using C. It is decided whether or not to use the license. By applying this location version, we can avoid breaking the consistency of the reference.

On the other hand, when an application has a corresponding method call to collect an object, the application program interface and the selective object collector have a multi-level collection algorithm. If the selected object is already liberalized, the collection operation is terminated and a specific exception is thrown to the application. If the finalize method exists, the finalization operation is completed and the actual object collection operation is performed.

Hereinafter, with reference to the drawings will be described an embodiment of the present invention;

1 is a block diagram showing an implementation of an application program interface between an application and a virtual machine according to the present invention. Although the virtual machine 150 shown in FIG. 1 includes the selection object collector 170 as an example, the user interface is also provided to the virtual machine 150 without the selection object collector 170 and the system interface 162. 160 may be applied. This is to determine whether explicit dynamic memory management is supported or unsupported, and ignore the application's request where it is not supported. That is, when the virtual machine 150 without the system interface 162 and the selection object collector 170 receives the selection object collection request from the application 100, the application program interface 160 sends a specific exception object to the application. This is because the virtual machine does not need to be operated or generated. Here, the selection object refers to the object that the application programmer explicitly selects to collect the object.

The application 100 can be written not only in an object-oriented language that supports automated dynamic memory management functions such as Java, C #, and LISP, but also in an object-oriented language, such as C ++, which does not have automated dynamic memory management. It refers to applications that use dynamic memory management in the form of libraries.

A virtual machine (150, VM) is software that acts as an interface between the byte code of a compiled application and the microprocessor (or hardware platform) that actually executes the instructions of the program. It specifies the instruction set, set of registers, stack, heap, and method area. Although such a virtual machine includes several subsystems, only the application program interface and the selective object collector required for the practice of the present invention are shown.

The application program interface 150 is a special method predetermined by the virtual machine so that an application can make a specific processing request to the virtual machine. The application program interface 150 is divided into a user interface 161 and a system interface 162. According to the present invention, the user interface 161 which receives a collection of selected object collection methods from an application sends a specific exception object to the application or transmits a collection of selected object collection methods to the system interface. The action taken is determined by the presence or absence of the system interface 162. If this is present, the system interface is called, but the exception object is sent to the application if it is not present. In addition, the system interface 162 that receives the selected object method call from the user interface 161 also sends a specific exception object to the user interface or passes the selected object method call to the object collector. In order to efficiently manage the dynamic memory, an interface method for passing the selective object collection method or responding to an exception object occurrence applied to the present invention will be described in detail with reference to FIG. 2.

The selective object collector 170 functions to collect garbage similarly to the function of a conventional garbage collector, but there is a substantial difference. Conventional garbage collectors automatically identify garbage objects that the application will no longer use when dynamic memory reaches a complete state due to the continuous object creation request of the application when the application is executed on a platform, etc., and return them to free memory. However, the selection object collector 170 collects a specific selection object only at the request of an application. That is, when there is a request for collecting a selection object, the selection object collector collects an object in real dynamic memory by calling a native method to collect the object. An algorithm for collecting the selection object in the selection object collector 170 will be described later in detail with reference to FIG. 3.

FIG. 2 is a diagram illustrating an overall flow chart of selection object collection when an application intends to collect an unused object in association with the application, user interface, system interface, and selection object collector shown in FIG. 1.

The application is provided with a method for collecting an object, so when the user wants to collect a single object or to collect not only the object but all the objects referenced by the object, the method is called 210. The user interface in the virtual machine takes specific actions by the methods called from the application. In other words, it checks for the existence of the system interface and calls it if it exists, but if it does not exist, it sends a special exception object to the application. If an application attempts to collect a special object that should not be collected, it passes an exception 211 to the application, which says that the object is not available for collection and terminates the collection without passing any methods to the system interface, while If not, the collection method is passed to the system interface (220). The reason for having the above user interface is that there is no selection object collector in the current Java virtual machine. If the selection object collector is included in the Java virtual machine in the future, the above check in the user interface is unnecessary. However, the handling of cases where there are special objects that should not be collected should be made available to the selection object collector.

The system interface appears to the general Java programmer in the form of Java API (Application Programming Interfaces), but inside the virtual machine, it is actually implemented as a native method.

After receiving the collection request from the user interface through the above steps, the selective object collector sends a null pointer exception object to the system interface so that the application receives the collection object when the collection requested object is already a liberated object. End the method operation (231, 232, 233). If it is a normal object that is not collected, it will collect the selected object.

3 is a flowchart illustrating an algorithm in which the selection object collector collects the selection object.

First, the selective object collector which receives the selective object collection method from the application program interface determines whether the object to be collected is already a liberalized object (S301) and returns a null pointer exception object when the object is already liberalized (S301a). S309) and ends the operation. In addition, the location version of the object reference variable in the collection request is compared with the location version stored in the requested object information area, and even if it is different, the null pointer exception object is returned and the operation ends. If the object is not a liberalized object, that is, an object that is normally alive (S301b), it is checked whether it has a finalize method (S302). If it is determined that the object does not have a finalization method (S302b), it does not proceed with the finalization operation but immediately locks the dynamic memory (S306) and collects the object. If S has a finalization method (S302a), after performing the finalization thread (S303, S304, S305) and locks the dynamic memory (S306). This finalization operation stops the execution of all application threads (S303), resumes execution of the finalization thread in charge of finalization operation, and resumes thread execution of all applications again after finishing the finalization operation (S304). S305). Finalization here is a mechanism supported in Java that allows you to organize related information yourself by giving it a last chance to clean itself before retrieving objects that are no longer referenced. In other words, if the object to be collected was using the system resources, it is possible to release the system resources for efficient use of system resources.

After acquiring the lock on the dynamic memory (S306), a function related to object liberalization that is already implemented in the automated dynamic memory manager, that is, a function in charge of the collection function of the actual memory level is called to perform the actual collection operation (S307). Then, by unlocking the heap again (S308), the object collection is completed.

On the other hand, existing virtual machines utilize pointers to access objects on the heap. Therefore, if you declare an object reference A, set A to point to a specific object, and then execute the bytecode that compiled the source in the virtual machine, the object reference A points to a portion of the dynamic memory area and the indicated dynamic The memory area contains the contents of the actual object. For example, if the object indicated by object reference A contains an integer of 144, when the compiled bytecode is executed in the virtual machine, the virtual machine inserts 144 into the appropriate dynamic memory area, eg, Ox80000000. The object reference A itself stores an address pointer of Ox80000000. Therefore, when the application collects the object pointed to by the object reference A according to the method described with reference to Figs. 2 and 3, 144 in Ox800000000 is erased, and the corresponding dynamic memory address becomes empty, and the object reference A also has an address pointer. It is cleared and nulled.

However, if you look at the flow of the program in Table 1, you can see that the consistency of references is broken when another variable refers to the object to be collected. Here, it is assumed that the object references A, B, and C can refer to the same type of object.

public class XXXX {

Object Reference A = Create Object ............ ①

Object Reference B = Create Object ............ ②

Integer member of object reference A = 144 ............ ③

Object Reference B = Object Reference A ............ ④

Collection of objects referenced by object reference A ............

Object reference C = object creation ............ ⑥

Integer member of object reference C = 154 ............

Print integer member value of object reference B ......

}

TABLE 1

In Table 1, all object references that have a reference to the object as well as the object collected at the time of collection of the object indicated by the object reference A (line ⑤) no longer point to any object. If the object reference A is collected by calling the object collection method, the object pointed to by the object reference B referencing it is the same as the object pointed to. Will recognize a null pointer. Therefore, you do not have to worry about errors due to mismatches in the reference variables. However, a problem occurs when another object is created at the same location after the object pointed to by the object reference A is collected. This is because, upon collection of the object pointed to by object reference A, no appropriate action has been taken on object reference B that refers to that object. Thus, even after the collection of objects pointed to by object reference A, object B still points to Ox80000000, creates a new object at that location, and stores the value 154 in the integer member of that object. By referencing a later object rather than an object, the application programmer sees a different result than intended.

This is because a Java virtual machine such as Kaffe stores objects of the same size in the same block. An object with a value of 154 as an integer member in line ⑥ is created in line ① and collected in line ⑤. Is stored in the exact same location as the dynamic memory area of Ox80000000. Therefore, if you try to access the object by referring to B before line ⑥, a null pointer exception object will occur (because Ox80000000 pointed to by object B's pointer is already collected), but at line ⑧ after line ⑥ In the case of accessing an object with reference to B, the object created in line ⑥, that is, it points to the same address as the pointer Ox80000000 of the object C, eventually prints the value of 154 stored in Ox80000000.

That is, unlike the programmer's intention to use the B value of 144 by referring to the object reference A when using the object reference B in line (8), the virtual machine uses the value 154 by referring to the object reference C. Thus, to solve this, you can use a method that finds all other object variables referencing the object and modifies them to null values when collecting an object. High overhead is incurred because the heap must be searched.

Therefore, a description will be given of a method of applying the position version technique in creating and collecting object variables so as to avoid excessive overhead in collecting objects and at the same time operating program logic exactly as intended.

Existing virtual machines store only pointers to addresses in dynamic memory where the actual variable values are stored in the object variable area when creating object variables that have been compiled and passed in the application. In addition, the dynamic memory includes an object information area in addition to the object value at the corresponding address. The information area is an area in which the color or current state information of the object is stored, and the user application can access the remaining areas except the information area, and the information area is only accessible to the virtual machine.

The location version algorithm proposed by the present invention stores the location version in the object reference area and the object information information in the dynamic memory, thereby comparing and determining the location version of each object when the object is used by the application. To keep. That is, the object reference stores a specific location version value as well as a pointer to a dynamic memory address where the actual value of the object reference is stored. In addition, in the dynamic memory address area in which the reference variable of the corresponding address object of the dynamic memory is stored, the position version is stored together with the reference variable value. If these two version information is the same, the application can access the object through the reference variable, but in other cases, the system with the virtual machine prevents access to it because the object referenced by the reference variable is different from the actual object. It throws something like a null pointer exception object and passes it to the application.

4 shows how the location version is stored.

When the bytecode compiled for variables for several objects in a data structure is executed on a system with a virtual machine installed, the object variables are stored in the object reference area 413, which contains the objects It includes an address pointer 411 indicating the stored address and position version information 412 of this object. In addition, the dynamic memory address where the object is stored has an actual object area 421 and an object information area 422 for such an object. The information area 421 has the same location version 412 as the location version stored in the object reference. This is because the system that manages the object stores the location version in the object information area additionally for each object. Even if an object is collected later, the location version 421 in the object information area may leave the location version where the object is located and use it by incrementing the value by 1 when a new object is created here.

The method of establishing the identity of the location version 412 stored in the object reference and the location version 421 stored in the object information area of the dynamic memory reads the value of the location version of the area when the object is created or collected in the area. And increase it by 1 and store it again in the object information area, and then store this value in the location version area 412 of the object reference area 413 to achieve the location version identity.

As such, the location version is stored in the location version area 412 of the object reference and the object information area 421 of the dynamic memory, so that when the location version stored in the object reference and the location version stored in the object information area are different from each other, the application refers to the corresponding object reference. This disables access to objects stored in dynamic memory.

For example, when the object pointed to by the object reference A in line ⑤ in Table 1 is collected, the value 154 of the integer member of the object in the heap is collected and erased, but the position version in the object information area (assuming 3 here). Will remain the same. The object version pointed to by object reference B already refers to the object pointed to by object reference A before collection of the object pointed to by object reference A, so the position version of object reference B is 3.

On the other hand, when the object pointed to by C is created in the future, the object pointed to by the existing A is created as it is in the dynamic memory area where the object pointed by the existing A is stored. Modify and save the location version of the area, and also store the location version value 4 in the object information area in the object pointed to by C. Therefore, when the application uses the object reference C, the virtual machine allows access to the object pointed to by C because the location version in the object variable and the location version in the object information area in the heap are equal to 4. On the other hand, if the application attempts to output the integer member value of the object pointed to by B (line ⑧), the position version value 3 of the object reference B and the object position version value 4 of the heap to which it points are not identical. The machine allows the application to block object accesses using object references B and return exceptions to the application, thereby preventing errors in the consistency of references caused by misuses of object variable references. When an application programmer passes such an exception, it knows that the object is missing and can implement a solution.

5 is a diagram illustrating a state in which a location version is stored in an object variable.

In most virtual machine implementations, the 32-bit environment creates an object with 8 bytes of alignment. Therefore, only 29 bits 510 of the 32 bits are used as pointers, and the lower 3 bits 520 are always filled with zeros, which means that meaningless information is stored and wasted. Therefore, location version information having values from 0 to 7 can be distinguished and stored in eight steps using the lower 3 bits. In 64-bit environments, the lower 3 bits can be increased in size.

Meanwhile, in order to apply the selection object collection algorithm using the position version described above, in the flowchart shown in FIG. 3, a process of checking the position version between the liberalized object determination and the finalization method existence determination is performed. In other words, when it is determined that the result of liberalization object is not determined, it is determined whether the location version stored in the object variable and the corresponding location version in the dynamic memory are the same. When the city generates a null pointer exception object indicating that the object is inaccessible, the collection of the object is terminated.

Although the technical spirit of the present invention has been described in detail according to the above-described preferred embodiment, the above-described embodiment is for the purpose of description, and various ordinary embodiments of the present invention may be made by those skilled in the art. I can understand.

As described above, the present invention allows a programmer to explicitly collect objects with minimal programming overhead while still using the same in a system using a conventional garbage collector, thereby maintaining the stability of the performance of the application. You can save resources. For example, suppose that there is 1M of dynamic memory and the objects corresponding to the size of 200KB are freed up by the programmer in the method proposed in the present invention. You get it. In addition, it is possible to postpone collector start time by the amount of time that is required to create 200KB of memory for an object of an application. An application that required three collections could complete its work with only one or two collections, thus gaining time.

Claims (6)

In the method for creating an object in a system running an application program, Storing a location version of the location of the created object in an object information area on a dynamic memory containing information about the object; When the generated object reference is intended to point to a specific object, storing a location version of the object in the object reference area together with the object reference; Method for creating an object in an automated dynamic memory-based system comprising a. The method of claim 1, wherein storing the location version in the object information area includes: A method of creating an object in a dynamic memory based system, comprising: reading a location version in a corresponding object information area, incrementing it by one, and storing it in the object information area again. The method of claim 1, wherein the storing of the location version in the object reference region comprises: A method for creating an object in an automated dynamic memory based system, comprising storing a location version identical to a location version of a corresponding object in a dynamic memory object information area in an area wasted when storing an address pointer among object reference areas. Passing a method of collecting an object that is no longer used by the application to the system; When the above system does not have the function of collecting the selection object, upon request for collection of dynamic memory or object explicitly, the system passes the exception object related to this error to the application and ignores the collection request. An interface step; And If the collection method execution exception is not delivered to the application, the collection process for collecting the selected object in dynamic memory. An application having a method for directly collecting an object stored in a dynamic memory. The method of claim 4, wherein the collection of the selected objects, If the selection object to be collected is already a liberalized object, the system determines that the liberalization object passes a null pointer exception to the application indicating that the selection object is already liberalized and terminates the collection of selected objects. step; If the system supports the location version algorithm that indicates the location of the object, the location version stored in the object information area and the location version area of the object reference are compared and judged. A location version determining step of transmitting and ending a selection object collection method operation; Performing a finalizing operation when a finalizing operation for releasing system resources used by the object to be collected is required; Obtaining a lock on the memory; Erasing the contents of the dynamic memory area including the object to be collected; And Steps to Delete a Lock on Dynamic Memory Method for directly collecting the object stored in the dynamic memory, characterized in that the application. The method of claim 5, wherein performing a finalize method comprises: A method in which an application directly collects an object stored in dynamic memory after the execution of all applications is stopped and finalization is performed again.