JP2006039878A - Memory management method and memory management program in java (r) execution environment - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To attain efficient data cooperation with a native program. <P>SOLUTION: When a request for the allocation of a Java(R) object to a heap region is issued, the Java(R) object is classified into a first type of Java(R) object and a second type of Java(R) object by a data type. When there is no vacancy in a first memory region to which the first type of Java(R) object is allocated, first compaction processing is executed to the first memory region, and when there is no vacancy in a second memory region to which the second type of Java(R) object is allocated, second compaction processing different from the first compaction processing is executed to the second memory region. Then, the first type of Java(R) object is allocated to the first memory region where vacancy is generated by the first compaction processing, and the second type of Java(R) object is allocated to the second memory region where vacancy is generated by the second compaction processing. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a memory management method and a memory management program in a Java (R) execution environment.

  Java (R) technology developed by Sun Microsystems developed especially in the Internet world, and was later used for development of server-side Java (R) and application software. Recently, it is also used for mobile phones. ing. Java (R) programs used in mobile phones often handle multimedia data such as audio, still images, and moving images. Especially in recent years, the size of these multimedia data tends to increase rapidly as the communication speed increases and the display screen becomes higher in definition.

  When such multimedia data is played back or processed, this processing is generally performed by an external native program independent of the Java® execution environment. Therefore, in this case, a data linkage operation between the Java® execution environment and the native program is required. Here, examples of the native program include a decoder as a reproduction program for audio and moving images, an encoder as a recording program, and a communication protocol stack.

  The memory management mechanism provided in the Java (R) execution environment is designed to handle Java (R) objects efficiently, preventing garbage collection functions to collect memory that is no longer used and memory fragmentation. It is equipped with a compaction mechanism.

  However, there are cases in which Java (R) objects managed by such a memory management mechanism cannot be managed in the same manner as other Java (R) objects.

  For example, if there is a Java (R) object that is processed by a native program that operates asynchronously with the Java (R) execution environment, if compaction is performed by the memory management mechanism in the middle of processing, the data being processed by the compaction is changed. The problem arises that the program cannot be read from the native program.

  In order to deal with such a problem, when data handled by the Java (R) program is processed by the native program, the data is secured separately from the heap area allocated for the Java (R) program. There is a method of performing processing by a native program after copying to the memory area.

  In the above method, when the native program updates the data and then returns the processing from the native program to the Java (R) program, the heap of the data updated by the native program is used to ensure data consistency. Copying back to the area and writing back.

  As described above, when processing for copying data occurs between the heap area used by the Java (R) program and another memory area used by the native program, a large amount of memory capacity of the system is consumed. There is a problem that processing is delayed by the time required for copying. In particular, when handling audio or moving image data having a large memory size, the memory capacity is extremely large, and the processing delay becomes significant.

  The present invention has been made paying attention to such a problem, and an object thereof is a memory management mechanism and a memory management program used in a Java (R) execution environment, which have different characteristics. However, it is an object of the present invention to provide a memory management mechanism and a memory management program that can be efficiently managed, and in particular, can perform efficient data linkage with a native program.

  In order to achieve the above object, the present inventor has conducted research, and the frequency used by the native program differs depending on the data type of the Java (R) object, in particular, the Java (R) object of byte []. Has been found to be frequently used from native programs.

  The present invention has been made in view of the above knowledge, and the memory management method according to the first invention is a memory management method in a Java (R) execution environment, in which a Java (R) object is stored in a heap area. Object classification step of classifying the Java (R) object into the first type Java (R) object and the second type Java (R) object according to a data type when a request to allocate occurs If there is no free space in the first memory area to which the first type Java (R) object is allocated, the first compaction process is executed on the first memory area, and the second If there is no space in the second memory area to which the Java (R) object of this type is allocated, A compaction execution step for executing a second compaction process different from the first compaction process for the area; and the first type in the first memory area in which a space is generated by the first compaction process. And allocating the Java (R) object of the second type, and allocating the Java (R) object of the second type in the second memory area that has been vacated by the second compaction process. To do.

  According to a second aspect of the present invention, in the memory management method according to the first aspect, a Java (R) object to which a predetermined mark is assigned is allocated in the second memory area. In the compaction process, the compaction process is not performed on the Java (R) object to which the mark is added.

  In addition, according to a third aspect, in the memory management method according to the second aspect, a predetermined mark is assigned to a Java (R) object used from a native program.

  According to a fourth invention, in the memory management method according to any one of the first to third inventions, the second type Java (R) object has a data type of a one-dimensional array of bytes.

  The fifth invention is the memory management method according to any one of the first to fourth inventions, wherein the Java (R) object having the one-dimensional array of bytes is audio data, image data or communication data. is there.

  A memory management program according to a sixth aspect of the present invention is a memory management program in a Java (R) execution environment for linking data with a native program, and a Java (R) object is stored in a heap area as a processing means. When a request for allocation occurs, the Java (R) object is changed into a first type Java (R) object and a second type Java (R) according to the frequency used by the native program. Object classification processing for classifying objects, and first compaction processing for the first memory area when there is no free space in the first memory area to which the first type Java (R) object is allocated And the second type Java (R) object is allocated When there is no free space in the second memory area, a compaction process for executing a second compaction process different from the first compaction process on the second memory area, and the first compaction process The first type Java (R) object is allocated to the first memory area where a space is generated, and the second type is stored in the second memory area where a space is generated by the second compaction process. And an object allocation process for allocating the Java (R) object.

  According to a seventh aspect of the present invention, in the memory management program according to the sixth aspect of the present invention, a Java (R) object to which a predetermined mark is assigned is allocated in the second memory area. In the compaction process, the compaction process is not performed on the Java (R) object to which the mark is added.

  In addition, according to an eighth aspect, in the memory management program according to the seventh aspect, a predetermined mark is given to a Java (R) object used from a native program.

  According to a ninth invention, in the memory management program according to the seventh or eighth invention, the second type Java (R) object has a data type of a one-dimensional array of bytes.

  The tenth invention is the memory management program according to any one of the sixth to ninth inventions, wherein the Java (R) object having the one-dimensional array of bytes is audio data, image data or communication data. is there.

  According to the present invention, it is possible to use different memory areas to be subjected to different compaction processes according to the data type of the Java (R) object, so that different compaction processes can be applied according to the data type of the object. Thus, even if there are objects with different forms and properties, it is possible to perform memory management efficiently.

  The present invention is particularly suitable for a case where a memory area that is subjected to different compaction processing is selectively used for a Java (R) object of a data type frequently used by a native program and other objects. is there. In this case, by avoiding compaction processing for Java (R) objects used by the native program, it is not necessary to secure a memory area and copy operation to deal with object movement during compaction processing. Thus, it is possible to perform data linkage between the Java (R) program and the native program extremely efficiently.

  First, an outline of the present embodiment will be described. In the Java (R) execution environment, many Java (R) objects are used only by the Java (R) program, and are used by the native program when data is linked with the native program. Java (R) objects are a small part. Here, the Java (R) object used in the native program needs to cope with the movement of the address by the compaction process, but the other Java (R) object does not need such a countermeasure. Therefore, efficient memory operation can be realized by distinguishing and managing them.

  As a result of careful observation of the native program linked with Java (R) by the present inventor, it has been found that the Java (R) object used by the native program has a one-dimensional array of bytes as a data type in most cases. . Specific examples of Java (R) objects (byte [] objects) having a one-dimensional array of bytes include multimedia data such as audio data and image (including moving image) data, communication data, and the like.

  Therefore, in the present embodiment, a normal Java (R) object is classified as a first type Java (R) object, a byte [] object is classified as a second type Java (R) object, and the first type Java (R) object is classified. The (R) object is stored in the first area in the heap area, and the second type Java (R) object is stored in the second area in the heap area. Among the byte [] objects in the second area, a Java (R) object used by the native program is given a predetermined mark that prohibits movement during compaction processing during data linkage with the native program. To do. Here, Java (R) objects that are not moved are locked by setting the mark bit to the ON state. The locked Java® object is not subject to compaction processing and will not be moved, as will be described later. After the data linkage with the native program is completed, the mark bit is turned off and the lock is released.

  As a method for distinguishing whether to permit or prohibit movement during compaction processing, instead of assigning a predetermined mark to each Java (R) object, information on permission or prohibition of movement for each Java (R) object. A management table in which is written may be used.

  When a request for allocating a new Java (R) object to the heap area occurs, if there is not enough memory area to allocate, garbage collection processing for collecting memory that is no longer used, A compaction process is performed in which the memory areas in use that are finely divided are combined into a continuous memory area. In this case, compaction is performed in the first area in which the first type Java (R) object is stored. The process moves all objects and prevents fragmentation. On the other hand, in the compaction process for the second area in which the second type Java (R) object is stored, a compaction process different from this is executed. That is, the compaction processing here is performed by moving only the other objects without moving the objects that are locked with the mark bit set to the ON state.

  Then, a first type Java (R) object is allocated to the first memory area where a space is generated by the compaction process, and a second type Java is stored in the second memory area where a space is generated by the compaction process. (R) The object is allocated.

  As described above, in this embodiment, the byte [] object that is frequently used by the native program is arranged in the second memory area, and the mark bit of the object is set while the object is actually used by the native program. Set to ON state. The compaction process for the second memory area does not move the object whose mark bit is in the ON state. Therefore, the object used by the native program is not moved by the compaction process. Therefore, an operation for securing and copying a new memory area outside the heap area in order to cope with object movement by compaction processing becomes unnecessary, thereby enabling efficient data linkage with the native program. In this case, normal compaction processing is performed for objects other than the byte [] object, and therefore memory management similar to memory management in the conventional Java® execution environment is possible.

  The memory management (particularly compaction processing) applied to the second memory area involves an overhead because it involves determining whether or not the Java® object is locked, but the first memory area has a conventional memory. Since management is applied, the impact can be minimized.

  In addition, Java (R) objects used from native programs often have a large capacity especially in the case of multimedia data, and such Java (R) objects use the entire heap area used by the Java (R) execution environment. Generation of fragmentation becomes a problem when distributed and locked. However, in this embodiment, the Java (R) object used from the native is mainly arranged in the second memory area, so even if fragmentation occurs, the influence is limited to the second memory area. can do.

  Note that when an object other than the byte [] object is used from a native program, such an object must be copied to the outside of the heap area as in the conventional case because it is located in the first memory area. Because the frequency is very low, there is no problem.

  In addition, the normal Java (R) object and the Java (R) object linked with the native program have different sizes and lifespan trends. Therefore, the data that is frequently linked with the native program is separated from the low data. Management improves the efficiency of memory management.

  Furthermore, since no new extensions have been added to the Java (R) language specification, it is only necessary to modify the Java (R) execution environment, and there is no need to modify existing programs. Affinity can be maintained.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

  FIG. 1 is an explanatory diagram of a hardware configuration for carrying out the present invention. Here, a hardware configuration of an embedded device (for example, a mobile phone) equipped with the Java (R) execution environment of the present embodiment is shown. Yes. In FIG. 1, a memory 11 is a part for storing various programs and data. The input / output unit 13 serves as a user interface and includes input keys, a microphone, a speaker, and the like. The display unit 12 is a part for displaying information such as various menus and operation statuses. The CPU 10 is a part that controls the operation of each part of the apparatus. The Java (R) object classification function, the memory area compaction function, and the Java (R) object allocation function used in this embodiment are virtually constructed when the CPU 10 reads and executes various programs stored in the memory 11. It has come to be.

  FIG. 2 is an explanatory diagram of a software configuration for carrying out the present invention. As shown in FIG. 2, on a platform (OS and hardware) 23, a VM (Virtual Machine) 24, a class library 22, and a Java (R) application 20 are mounted as a Java (R) execution environment. The VM 24 is a program that is executed while converting a class file storing Java (R) bytecode into native code.

  The VM 24 has a Java (R) heap area 25. Here, as shown in FIG. 3, the first area 25-1 to which a normal Java (R) object is allocated, and a byte [] object are stored. A second region 25-2 to be allocated is provided. Furthermore, native program applications 1 (26) and 2 (27) for performing data linkage (read / write) with the Java (R) execution environment are installed.

  FIG. 4 is a flowchart showing a procedure for allocating a Java (R) object by the method of this embodiment.

  When a request for allocating a Java (R) object to the heap area occurs, the CPU 10 determines whether or not the data type of the Java (R) object is byte [] (step S1). That is, if it is a normal Java (R) object, it is determined whether or not there is a free space in the first area 25-1 of the Java (R) heap area 25 (step S2). If the determination here is YES, the Java (R) object is allocated to the first area 25-1 (step S5), and then the process ends.

  If the determination in step S2 is NO, garbage collection is performed on the first and second areas 25-1 and 25-2 to release unused areas, and the first area A compaction process for moving the Java (R) object in use in 25-1 is executed (step S3). Next, it is determined whether or not an empty space has been generated in the first area 25-1 by the above-described garbage collection and compaction process (step S4). If YES, Java (R ) Allocate the object (step S5), and then end. On the other hand, if the determination in step S4 is NO, an error message indicating no free space is displayed (step S6), and the process ends.

  On the other hand, if the determination in step S1 is yes, it is determined whether or not there is a free space in the second area 25-2 of the Java (R) heap area 25 (step S7). If the determination here is YES, the Java (R) object is allocated to the second area 25-2 (step S10), and then the process ends.

  When the determination in step S7 is NO, garbage collection is performed on the first and second areas 25-1 and 25-2 to release unused areas, and the second area A compaction process for moving only the unlocked Java (R) object in 25-2 is executed (step S8). Next, it is determined whether or not an empty space is generated in the second area 25-2 by the above-described garbage collection and compaction processing (step S9). If YES, Java (R ) Allocate the object (step S10), and then end. On the other hand, if the determination in step S9 is NO, an error message indicating no free space is displayed (step S6), and the process ends.

  The present invention is not limited to the above embodiment, and various modifications can be made. For example, even when a language system succeeding Java (R) is newly proposed, if the language system assumes memory management such as garbage collection and compaction by the execution environment, the memory of the present invention The management method and the memory management program can be applied in the same manner as in the above embodiment. Moreover, there is no restriction | limiting in the method of garbage collection or compaction, The applicable method can be used suitably. Also, the timing of performing garbage collection and compaction is not limited to the above embodiment, and these may be performed asynchronously with the timing of generation of a request for allocating a Java (R) object.

It is explanatory drawing of the hardware constitutions for implementing this invention. It is explanatory drawing of the software structure for implementing this invention. It is a figure which shows two area | regions for allocating a Java (R) object. It is a flowchart which shows the procedure which allocates a Java (R) object by the method of this embodiment.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 ... CPU, 11 ... Memory, 12 ... Display part, 13 ... Input / output part, 20 ... Java (R) application, 21 ... AMS, 22 ... Class library, 23 ... Platform, 24 ... VM, 25 ... Java (R) Heap area, 25-1 ... first area, 25-2 ... second area, 26 ... native application 1, 27 ... native application 2.

Claims (10)

A memory management method in a Java (R) execution environment,
When a request for allocating a Java (R) object to the heap area occurs, the Java (R) object is classified into a first type Java (R) object and a second type Java (R) depending on the data type. An object classification step for classifying objects;
When there is no free space in the first memory area to which the first type Java (R) object is allocated, the first compaction process is executed on the first memory area, and the second type Compaction that executes a second compaction process different from the first compaction process on the second memory area when there is no free space in the second memory area to which the Java (R) object is allocated Execution steps;
The second memory in which the first type Java (R) object is allocated to the first memory area in which free space has been generated by the first compaction processing, and free space has been generated by the second compaction processing. An object allocation step for allocating the second type Java object in a region;
A memory management method comprising: In the second memory area, a Java (R) object to which a predetermined mark is assigned is allocated, and in the second compaction process, a compaction process for the Java (R) object to which the mark is assigned is performed. The memory management method according to claim 1, wherein the memory management method is not performed. 3. The memory management method according to claim 2, wherein a predetermined mark is assigned to a Java (R) object used from a native program. 4. The memory management method according to claim 1, wherein the second type Java (R) object has a data type of a one-dimensional array of bytes. 5. 5. The memory management method according to claim 1, wherein the Java (R) object having the one-dimensional array of bytes is audio data, image data, or communication data. A memory management program in a Java (R) execution environment that performs data linkage with a native program,
In processing means,
When a request for allocating a Java (R) object to the heap area occurs, the Java (R) object is classified into a first type Java (R) object and a second type Java (R) depending on the data type. Object classification processing to classify objects,
When there is no free space in the first memory area to which the first type Java (R) object is allocated, the first compaction process is executed on the first memory area, and the second type Compaction that executes a second compaction process different from the first compaction process on the second memory area when there is no free space in the second memory area to which the Java (R) object is allocated Processing,
The second memory in which the first type Java (R) object is allocated to the first memory area in which free space has been generated by the first compaction processing, and free space has been generated by the second compaction processing. An object allocation process for allocating the second type Java (R) object in a region;
A memory management program. In the second memory area, a Java (R) object to which a predetermined mark is assigned is allocated, and in the second compaction process, a compaction process for the Java (R) object to which the mark is assigned is performed. The memory management program according to claim 6, wherein the memory management program is not performed. 8. The memory management program according to claim 7, wherein a predetermined mark is assigned to a Java (R) object used from a native program. 9. The memory management program according to claim 6, wherein the second type Java (R) object has a data type of a one-dimensional array of bytes. The memory management program according to any one of claims 6 to 9, wherein the Java (R) object having a one-dimensional array of bytes is audio data, image data, or communication data.

Images