KR20070083274A - Method for excuting java virtual machine on mobile communication terminal by using fast memory access bytecode - Google Patents

Abstract

A method for executing a JVM in a mobile terminal by using a fast memory access bytecode is provided to improve an execution speed of an application executed in the mobile terminal by not repeatedly executing a process of checking whether a class, a field, or the method is valid. While the application is executed in the mobile terminal, a Putfield bytecode is called(S100). If the Putfield bytecode is executed, field data of a destination field is changed(S110). The Putfield bytecode is updated by an X-Putfield bytecode(S112). A constant pool index, which is a parameter of the Putfield bytecode, is updated by offset data(S114). The X-Putfield bytecode is called and searches the offset data, which is the parameter(S116). The field data of other destination fields is changed(S118). If a termination signal for the JVM is generated when the application is terminated, the X-Putfield bytecode is updated by the Putfield bytecode and the offset data is updated to the constant pool index(S120).

Description

Method for Excuting Java Virtual Machine on Mobile Communication Terminal by Using Fast Memory Access Bytecode}

1 is a flowchart illustrating a process of executing X-Putfield, which is a fast memory access bytecode, in a Java virtual machine according to an embodiment of the present invention.

2 is a flowchart illustrating a process of executing X-Getfield, which is a fast memory access bytecode, in a Java virtual machine according to an exemplary embodiment of the present invention.

The present invention relates to a Java virtual machine execution method on a mobile communication terminal using fast memory access bytecode. More specifically, when using a Java virtual machine in a mobile communication terminal using Putfield and Getfield, Putfield and Getfield are used at the first time while the Java virtual machine is running, and after the first time, X is putfield and Getfield. Update the fast memory access bytecode that runs the Java virtual machine by updating with Putfield and X-Getfield and updating the Constant Pool Index parameter of Putfield and Getfield with an offset derived from the field information. The present invention relates to a Java virtual machine execution method on a mobile communication terminal.

The mobile communication system has been developed through the first generation analog AMPS (Advanced Mobile Phone System) method and the second generation cellular (Cellular) / Personal Communication Service (PCS) method. The third generation mobile communication system IMT-2000 (International Mobile Telecommunication 2000), which is enacted as a standard in ITU-R, is commercially available. IMT-2000 is CDMA 2000 1X, 3X, EV-DO, Wideband CDMA (WCDMA), etc., and is used in IS-95A and IS-95B networks by using the IS-95C network that has evolved from the existing IS-95A and IS-95B networks. It is a service that can provide wireless Internet at a transmission speed of up to 144 Kbps, much faster than the supportable data transfer rate of 14.4 Kbps or 56 Kbps. In particular, by using IMT-2000 service, it is possible to provide various multimedia services (AOD, VOD, etc.) at a faster speed as well as improving existing voice and wireless broadcasting service (WBS) service quality.

In addition, recently, as a part of overcoming the limitations in providing the wireless Internet service of the above-described mobile communication system, a portable Internet system (HPi: High Speed) capable of using high-speed wireless Internet service at a low cost while moving Development of the Portable Internet System or WiBro: Wireless Broadband Internet System. The portable internet system can use various information and contents by accessing the Internet in indoor and outdoor stationary environment and mobile environment of walking speed and low to medium speed by using various types of portable terminals such as laptop, PDA, handheld PC. It is a service. In addition, it enables mobile subscribers to use the wireless Internet while moving at a speed of 60 km / h, provides a downlink transmission speed of 24 Mbps, and a downlink transmission of 50 Mbps using a multiple input multiple output (MIMO) system. It is an IP (Internet Protocol) based wireless data system that can provide speed.

The mobile subscriber can use the mobile communication system to carry voice communication while carrying the mobile communication terminal, and wirelessly access the Internet through the mobile communication system using the wireless Internet technology to transmit text, images, Multimedia data services such as voice or video are provided. The wireless Internet allows a mobile subscriber to search and download a variety of information by accessing the Internet using a mobile communication terminal without time or space constraints.

Recently, with the development of the Internet and multimedia data technology, a content provider (CP) that provides various contents such as multimedia communication, network game, and video game has emerged, and various services provided by the content provider are provided as mobile communication terminals. The number of mobile subscribers to use has increased.

In addition, the hardware of the mobile communication terminal continues to evolve in accordance with the service provided. Early models only supported voice calls and short message services, but the camera was installed on the mobile terminal so that users could take pictures, and the mobile communication terminal was equipped with a module capable of playing sound. In recent years, hardware developments have been made up to mobile communication terminals equipped with a module capable of reproducing and receiving satellite broadcasting.

Meanwhile, as the services provided to the mobile communication terminals are diversified, the applications executed to use various services in the mobile communication terminals are also diversified. Applications used in mobile communication terminals are made using a Java Vurtual Machine.

Java is an object-oriented programming language that is a collection of classes. A class consists of a field and a method, and an application used in a mobile communication terminal executes a program by calling a method of each class to change field data (state of a class). Therefore, Java's bytecode defines not only general operations but also bytecodes for operations on classes.

Unlike general opcode bytecodes, bytecodes for classes are complex, such as retrieving classes, fields, and methods, retrieving actual methods by inheritance and interface definitions, and calling and executing classes, fields, and methods. Should go through

However, the process of retrieving classes, fields, and methods for valid data and the availability of classes, fields, and methods while the new application is running and running is only required once the application is running. The bytecodes defined in Putfield and Getfield allow you to repeatedly search for classes, fields, and methods to verify that they are valid data, and to check whether classes, fields, and methods are available, each time you use Putfield and Getfield. There was a problem that slows down the application execution.

In order to solve this problem, the present invention, when using a Java virtual machine in a mobile communication terminal using Putfield and Getfield, while the Java virtual machine is running the first time using Putfield and Getfield, after the first one Updates Putfield and Getfield to X-Putfield and X-Getfield, and updates the Constant Pool Index Parameters of Putfield and Getfield with an offset derived from the field information to run the Java virtual machine. It is an object of the present invention to provide a method for executing a Java virtual machine on a mobile communication terminal using memory access bytecode.

In order to achieve this object, according to the first object of the present invention, a Java virtual machine execution method of a mobile communication terminal using fast memory access bytecode, comprising: (a) Putfield bytecode while executing an application in the mobile communication terminal; Calling; (b) changing the field data of the target field when the Putfield bytecode is executed; (c) updating the Putfield bytecode with the X-Putfield bytecode; (d) updating the constant full index, which is a parameter of the Putfield bytecode, with offset data; (e) calling an X-Putfield bytecode, and retrieving offset data in which the X-Putfield bytecode is a parameter; (f) altering field data of another destination field; And (g) updating the X-Putfield bytecode to Putfield bytecode and updating the parameter offset data to a constant pool index when the termination signal for the Java virtual machine is generated by terminating the application. A method of executing a Java virtual machine of a mobile communication terminal using fast memory access bytecode is provided.

According to a second object of the present invention, there is provided a method of executing a Java virtual machine of a mobile communication terminal using fast memory access bytecode, the method comprising: (a) calling a Getfield bytecode while executing an application in the mobile communication terminal; (b) when Getfield bytecode is executed, acquiring field data stored in a target field and storing the data at the top of the stack; (c) updating the Getfield bytecode with the X-Getfield bytecode; (d) updating the constant pool index, which is a parameter of Getfield bytecode, with offset data; (e) calling the X-Getfield bytecode, and retrieving offset data in which the X-Getfield bytecode is a parameter; (f) acquiring and storing field data stored in another destination field at the top of the stack; And (g) updating the X-Getfield bytecode to Getfield bytecode and updating the parameter offset data to a constant pool index when the termination signal for the Java virtual machine is generated by terminating the application. A method of executing a Java virtual machine of a mobile communication terminal using fast memory access bytecode is provided.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. First of all, in adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are used as much as possible even if displayed on different drawings. In addition, in describing the present invention, when it is determined that the detailed description of the related well-known configuration or function may obscure the gist of the present invention, the detailed description thereof will be omitted.

In addition, hereinafter, the present invention will be described under the assumption that a code division multiple access (CDMA) 2000 system is used as the mobile communication system. However, the CDMA 2000 system is a system designated for convenience of description and the mobile communication system used in the present invention is not limited thereto.

1 is a flowchart illustrating a process of executing X-Putfield, which is a fast memory access bytecode, in a Java virtual machine according to an exemplary embodiment of the present invention.

While executing and operating an application in the mobile communication terminal, the Putfield bytecode is called in order to change the field data for the designated destination field of the object in the Java virtual machine (S100).

Putfield bytecode is a bytecode for changing the field data of the object field of the object in the Java virtual machine. It has a constant pool index of 2 bytes as a parameter. Data and objects reside on the stack.

When the putfield bytecode is executed, the constant pool index searches for information on a target field for changing field data, and checks whether the information on the searched target field is valid data (S102).

In the present invention, the information on the object field is information including the class and offset data of the object field in the object.

If it is determined in step S102 that the information on the target field retrieved is valid, it is checked whether the class for the target field is loaded (S104).

If it is determined in step S102 that the information on the searched destination field is invalid, an error message is generated and the generated error message is transmitted to the application manager (S106).

If it is determined in step S104 that the class for the target field is not loaded, the class is loaded into the memory using the class loader (S108).

If it is determined in step S104 that the class for the target field is loaded, the memory address in which the field data is stored is calculated from the information on the target field to change the field data of the target field (S110).

When the change of the field data for the target field is completed, the Putfield bytecode is updated to the X-Putfield bytecode (S112).

After updating the Putfield bytecode to the X-Putfield bytecode, the constant pool index, which is a parameter, is updated with offset data (S114).

In order to change the field data for another destination field in the Java virtual machine while the application is running, the X-Putfield bytecode is called, and the X-Putfield bytecode retrieves a parameter offset (S116).

The memory address for storing the field data of the target field is calculated from the object of the stack and the offset data to change the field data of the target field (S118).

When the termination signal for the Java virtual machine is generated by closing the application, the X-Putfield bytecode is updated to Putfield bytecode, and the offset data, which is a parameter, is updated with a constant pool index (S120).

2 is a flowchart illustrating a process of executing X-Getfield, which is a fast memory access bytecode, in a Java virtual machine according to an exemplary embodiment of the present invention.

During the execution and operation of the application in the mobile communication terminal, the Getfield bytecode is called in order to obtain field data stored in the designated destination field of the object in the Java virtual machine (S200).

Getfield bytecode is a bytecode that performs the task of acquiring the field data stored in the object field of the object in the Java virtual machine. It has a constant byte index of 2 bytes as a parameter. The object exists on the stack and stores the field data stored in the object's destination field on the stack.

When Getfield bytecode is executed, information on the target field to obtain field data from the constant pool index is searched, and it is checked whether the information on the searched target field is valid data (S202).

In the present invention, the information on the object field is information including the class and offset data of the object field in the object.

If it is determined in step S202 that the information on the destination field is valid, it is checked whether the class for the destination field is loaded (S204).

If it is determined in step S202 that the information on the searched destination field is invalid, an error message is generated, and the generated error message is transmitted to the application manager (S206).

If it is determined in step S204 that the class for the target field is not loaded, the class is loaded into the memory using the class loader (S208).

If it is determined in step S204 that the class for the target field is loaded, the memory address in which the field data is stored is calculated from the information on the target field to obtain field data stored in the target field, and the acquired field data is stored at the top of the stack. Store in (S210).

When the change of the field data for the target field is completed, the Getfield bytecode is updated to the X-Getfield bytecode (S212).

After updating the Getfield bytecode to the X-Getfield bytecode, the constant pool index, which is a parameter, is updated with offset data (S214).

While the application is running, the X-Getfield bytecode is called to obtain field data stored in another object field in the Java virtual machine, and the X-Getfield bytecode searches for an offset which is a parameter (S216).

The memory data for obtaining the field data stored in the target field is calculated from the object of the stack and the offset data to obtain the field data stored in the target field (S218).

When the termination signal for the Java virtual machine is generated by terminating the application, the X-Getfield bytecode is updated to Getfield bytecode, and the offset data as a parameter is updated to the constant pool index (S220).

The above description is merely illustrative of the technical idea of the present invention, and those skilled in the art to which the present invention pertains may make various modifications and changes without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are not intended to limit the technical idea of the present invention but to describe the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The scope of protection of the present invention should be interpreted by the following claims, and all technical ideas within the scope equivalent thereto should be construed as being included in the scope of the present invention.

As described above, according to the present invention, in the case where the Java virtual machine is executed on the mobile communication terminal and the Putfield and the Getfield are used, the Putfield and the Getfield are used at the first time while the Java virtual machine is running. Define Putfield and Getfield as X-Putfield and X-Getfield, and update the Constant Pool Index Parameter of Putfield and Getfield with an offset derived from the field information to provide execution of the Java virtual machine. Java virtual machine execution of a mobile communication terminal using fast memory access bytecode to retrieve a class, field or method during execution and operation of a new application to check for valid data and to use the class, field or method. Only check once for the first time Not more than the unwanted repetitive execution has the effect of improving the execution speed of the application executing on the mobile terminal.

Claims (8)

In the method of running a Java virtual machine on a mobile communication terminal using Fast Memory Access Bytecode, (a) calling a Putfield bytecode while executing an application in the mobile communication terminal; (b) changing the field data of the destination field when Putfield bytecode is executed; (c) updating the Putfield bytecode with an X-Putfield bytecode; (d) updating a constant full index, which is a parameter of the Putfield bytecode, with offset data; (e) calling the X-Putfield bytecode, and retrieving the offset data where the X-Putfield bytecode is a parameter; (f) modifying the field data of the other destination field; And (g) updating the X-Putfield bytecode to the Putfield bytecode and updating the parameter offset data to the constant pool index when the termination signal for the Java virtual machine is generated by terminating the application. A method of executing a Java virtual machine on a mobile communication terminal using a fast memory access bytecode comprising a. The method of claim 1, wherein the Putfield bytecode, A byte code for performing a task of changing the field data of the object field of the object in the Java virtual machine, and having a constant pool index of 2 bytes as a parameter. A method of executing a Java virtual machine on a mobile terminal using access bytecode. The method of claim 1, Step (b) is, (b1) retrieving information on the destination field to change the field data from the constant pool index when the Putfield bytecode is executed; (b2) checking whether the information on the searched destination field is valid data; (b3) if it is determined that the information on the destination field retrieved in step (b2) is valid, checking whether the class for the destination field is loaded; (b4) generating an error message if it is determined that the information on the destination field retrieved in step (b2) is not valid, and transmitting the generated error message to the application manager; (b5) if it is determined in step (b3) that the class for the target field is loaded, calculating the memory address where the field data is stored from the information on the target field and changing the field data of the target field; ; And (b6) in the step (b3), if it is determined that the class for the destination field is not loaded, loading the class into the memory using a class loader; A method of executing a Java virtual machine on a mobile communication terminal using a fast memory access bytecode comprising a. The method of claim 3, wherein the information on the destination field, And information including the class of the destination field and the offset data in the object. A method of executing a Java virtual machine on a mobile terminal using fast memory access bytecode, (a) calling a Getfield bytecode while executing an application in the mobile communication terminal; (b) when the Getfield bytecode is executed, acquiring and storing the field data stored in the destination field at the top of the stack; (c) updating the Getfield bytecode with an X-Getfield bytecode; (d) updating the constant full index, which is a parameter of the Getfield bytecode, with offset data; (e) calling the X-Getfield bytecode, and retrieving the offset data where the X-Getfield bytecode is a parameter; (f) acquiring and storing the field data stored in the other destination field at the top of the stack; And (g) updating the X-Getfield bytecode to the Getfield bytecode and updating the parameter offset data to the constant pool index when the termination signal for the Java virtual machine is generated by terminating the application. A method of executing a Java virtual machine on a mobile communication terminal using a fast memory access bytecode comprising a. The method according to claim 5, wherein the Getfield bytecode, A bytecode for performing the operation of acquiring the field data stored in the object field of the object in the Java virtual machine, and having the constant pool index of 2 bytes as a parameter. A method of executing a Java virtual machine on a mobile terminal using fast memory access bytecode. The method of claim 5, Step (b) is, (b1) retrieving information on the destination field to obtain the field data from the constant pool index when the Getfield bytecode is executed; (b2) checking whether the information on the searched destination field is valid data; (b3) if it is determined that the information on the destination field retrieved in step (b2) is valid, checking whether the class for the destination field is loaded; (b4) generating an error message if it is determined that the information on the destination field retrieved in step (b2) is not valid, and transmitting the generated error message to the application manager; (b5) If it is determined in step (b3) that the class for the target field is loaded, the memory address in which the field data is stored is calculated from the information on the target field to store the field data stored in the target field. Acquiring and storing the acquired field data at the top of the stack; And (b6) in the step (b3), if it is determined that the class for the destination field is not loaded, loading the class into a memory using a class loader; A method of executing a Java virtual machine on a mobile communication terminal using a fast memory access bytecode comprising a. The method of claim 3, wherein the information on the destination field, And information including the class of the destination field and the offset data in the object.

Images