KR100936401B1 - Java bytecode translating method - Google Patents

Abstract

Java bytecode conversion method of the present invention is a bytecode patch step (S110) for patching a Java bytecode from a Java class file, and the operation code of the patched Java bytecode is a static field access bytecode for accessing a static field The first field address FA1 is detected by adding the static field address, which is a predetermined value, by combining the field offset of the object to be accessed by the operand of the patched bytecode. Accordingly, among the bits of the first field address FA1 detected in the static field address detection and data processing step S140 and the static field address detection and data processing step S140 that access the field 130 to process data. The first upper field address FAU1 composed of upper bits is stored in the first storage unit 110, and the remaining lower bits except for the first upper field address FAU1 among the bits of the first field address FA1. Consist of A static field address storing step (S150) for storing the first subfield address FAD1 in the operand field 120b, and an operation for accessing a new static field preset by the user in the operation code stored in the operation code field 120a. Java having a static operation code conversion step (S160) for converting to a code (NOPA), and the operation code (NOPA) converted in the static operation code conversion step (S160) the Java byte code patched in the byte code patch step (S110) If the byte code is a second field address (FAU1) stored in the first storage unit 110 and the first lower field address (FAD1) stored in the operand field (120b) of the patched Java byte code A first field address generation step S240 for generating FA2) and a first data processing step S250 for accessing the field 130 and processing data according to the second field address FA2.

Java Bytecode, Source Code, Static Fields, Object Fields, Field Addresses

Description

Java bytecode translating method}

The present invention relates to a method for converting Java bytecode, and in particular, when performing field access bytecode in Java bytecode, the field access bytecode is converted without proceeding to interpret the constant pool. The present invention relates to a Java bytecode conversion method that can significantly reduce the number and improve the performance of the Java virtual machine.

Java is often compiled into an intermediate language called Java Virtual Machine Language (JVM), which can be interpreted by the Java Virtual Machine, and the compiled result is called a class file. The file consists of bytecodes.

Because Java virtual machines are based on stack operations, all operands are stored on the stack before they are used, and the results of the operations are stored on the stack so that the host processor of the Java virtual machine is installed. It is possible to execute a written Java application regardless of the number of registers.

The Java programming language has the disadvantage of slow performance compared to code written in languages such as C and C ++. However, in order to overcome this problem, a software interpretation method, a just-in-time compilation method, AOT (Ahead-Of-Time) compilation method and hardware implementation method are used.

The software interpretation method is often used when resource constraints are severe, but the execution speed is slow because the interpretation of bytecode is performed by software. Both the JIT compilation method and the AOT compilation method require a large memory. .

The hardware implementation method is suitable for an embedded system because, unlike other methods, hardware can perform bytecode interpretation and speed up execution, and does not require much memory.

The software interpreter and the hardware interpreter are collectively called the Java interpreter. The Java interpreter has native code, which is the code that the Java virtual machine should execute for each bytecode. have. The Java interpreter executes bytecodes sequentially, and when one bytecode is fetched, it decodes and executes the bytecode as one or several source codes that perform the same operation as the corresponding bytecode. The hardware interpreter, however, is faster than having the code to execute in memory and then mapping the location of the code to hardware to perform the mapping process in software.

The bytecode is divided into an opcode that defines an execution operation and an operand used to perform the opcode. Since both the opcode and the operand are composed of one byte, there are 256 possible opcodes, but according to the Java Virtual Machine Specification, 202 opcodes are specified, and the rest are new bytes in the Java virtual machine. Define the code so that it can be used. This can be defined by converting the opcode into a new opcode that is not defined in the Java virtual machine specification during the execution of a particular bytecode. In addition, the operands can also be converted into data desired by the user.

When compiling a Java application, a class file is created by placing an operand after each operation code and the following operation code after the operand. Each operation code may or may not have multiple operands.

Fields are frequently accessed when executing Java applications. The bytecodes related to field access are static field access and object field access. In each case, bytecodes for writing and reading fields are used. There are two things. The bytecodes for accessing static fields are defined as 'getstatic' and 'putstatic', and the bytecodes for accessing object fields are defined as 'getfield' and 'putfield', both of which have two operands.

1 is a flowchart illustrating a process of a conventional field access bytecode.

As shown in FIG. 1, the conventional process of field access bytecode is applied to the bytecode patch step S1 for patching the bytecode from the class file, and the operation code of the bytecode patched in the bytecode patch step S1. The field access determination step (S2) for determining whether the bytecode patched by the byte code is for accessing the field and the bytecode patched in the field access determination step (S2) are not the bytecode for the field access. The execution step (S3) of jumping to the handler corresponding to the operation code to perform the corresponding bytecode, and if the bytecode patched in the field access determination step (S2) is the bytecode for the field access, the patched bytecode accesses the static field. A field discrimination step (S4) for determining whether a bytecode is for accessing a recognized object field and a bytecode patched at the field discrimination step (S4) are static fields. If getstatic or putstatic, the static field address detection step (S5) extracting the static field address, which is the first address of the static field of the specified Java virtual machine, and the bytecode patched in the field discrimination step (S4) access the object field. (getfield, putfield), the object field address detection step (S6) of detecting the object field address which is the first address of the object field by the object reference data stored on the top of the stack, and the constant pool (Constant) by the operand of the patched bytecode. An offset detection step (S7) for detecting a field offset of an object to be accessed by analyzing a pool, and a final field by adding the field offset detected in the offset detection step (S7) and the object field address or static field address. A field address calculating step (S8) for calculating an address, and a data processing step (S9) for processing data by accessing a field by the field address calculated in the field address calculating step (S8). It is made.

The data processing step S9 stores the data stored in the field of the field address at the top of the stack if the patched bytecode is getstatic or getfield, or the data stored just below the top of the stack if the patched bytecode is putstatic or putfield. Store in the field of the field address.

As shown in FIG. 1, when the patched bytecode is a bytecode related to field access, a constant pool must be interpreted in an offset detection step S7 to detect a field offset of an object to be accessed. In this case, since thousands of native codes are generally required only during the interpretation of the constant pool, performance degradation occurs in executing a Java application.

2A and 2B are flowcharts illustrating a conventional Java bytecode conversion method improved to prevent performance degradation when the Java application program of FIG. 1 is executed, and FIG. 3 is a view illustrating the conventional Java bytecode conversion method of FIG. A block diagram illustrating getfield for object field access.

The conventional Java bytecode conversion method shown in FIGS. 2A to 3 is proposed by SUN Microsystem in order to reduce the number of source codes in the case of field access bytecode, and the patched bytecode is bytecode for field access. These are converted to a new bytecode (eg 'x_quick', where x is one of getstatic, putstatic, getfield or putfield) to process the bytecode for field access.

That is, as shown in FIG. 2A, if the bytecode patched in a specific program counter is a bytecode for accessing a field (S11), the same process as the bytecode processing for accessing a field as shown in FIG. 1. Correspondingly, the corresponding constant pool is interpreted from the operand of the bytecode, and the field offset (FO) is detected by the constant pool analysis to process the field address (FA) and data (S13), and the field offset (FO). Is stored in the position of the operand 1b of the byte code (S15), and the operation code OP of the byte code is converted into 'x_quick', which is a new operation code (S17). Where x is one of getstatic, putstatic, getfield, or putfield. The converted opcode is then recognized as 'x_quick' by the Java virtual machine.

As shown in FIG. 2B and FIG. 3, the conventional Java bytecode conversion method is as follows.

The converted bytecode detection step S20 detects whether the operation code (OP) 1a of the patched bytecode 1 is 'x_quick', which is the operation code 1a of the bytecode for accessing the newly converted field. . If the bytecode is a bytecode for accessing the newly converted field in the converted bytecode detection step (S20), the field discrimination step (S30) determines whether the patched bytecode is a bytefield for accessing a static field or an object field. do. In the static field address detection step S40, if the bytecode patched in the field discrimination step S30 is a static field access (getstatic_quick, putstatic_quick), the static field address of the predetermined Java virtual machine is extracted. In the object field address detection step S50, if the bytecode patched in the field discrimination step S30 is the object field access (getfield_quick, putfield_quick), the object field address (OD) is stored by the object reference data OD stored at the top of the stack 3. 5) is detected. The field address calculation step S60 calculates the field address FA by adding the field offset FO stored in the operand 1b of the patched bytecode with the object field address or the static field address. The data processing step S70 accesses the field 7 by the calculated field address FA and processes the field data FD.

In the conventional Java bytecode conversion method shown in FIGS. 2A to 3, in the case of bytecode converted to a new bytecode when performing bytecode for field access, there is no need to perform constant pool analysis to detect a field offset. Compared to 1, the number of source codes can be significantly reduced, but the conventional Java bytecode conversion method should detect the object field address from the object reference data located at the top of the stack in the case of the byte code for accessing the object field. In order to calculate the field address, a lot of source code is required to perform the process because the field offset and the object field address or the field offset and the static field address stored in the operand of the newly converted bytecode must be added. Will still cause performance degradation when running Java applications. It has a point.

 An object of the present invention is to divide and store the field address calculated for the byte code for the field access divided into the operand and the storage of the byte code, and to convert the operation code of the byte code into a predetermined operation code, When the bytecode for the corresponding field access is patched, the field address is processed by processing the data by accessing the field by the field address by the operand and the data stored in the storage, and the field address for the static field access and the object field access can be quickly calculated. The purpose of the present invention is to provide a Java bytecode conversion method that can improve the performance of a Java application by reducing the number of source codes required for field address calculation.

In order to achieve the above object, the Java bytecode conversion method of the present invention comprises: a bytecode patch step of patching a Java bytecode consisting of an operation code field in which an operation code is stored and an operand field in which an operand is stored from a Java class file; If the operation code of the Java bytecode patched in the bytecode patch step is a static field access bytecode for accessing a static field, the field of an object to be accessed by interpreting a constant pool by an operand of the patched bytecode A static field address detection and data processing step of detecting a first field address by adding an offset and a static field address which is a predetermined value, and accessing a field according to the first field address to process data; A first upper field address composed of upper bits among the bits of the first field address detected in the static field address detection and data processing step is stored in a first storage means, and the first of the bits of the first field address is stored. A static field address storing step of storing a first lower field address consisting of remaining lower bits except for a first upper field address in the operand field; A static operation code conversion step of converting an operation code stored in the operation code field into an operation code for accessing a new static field preset by a user; If the Java bytecode patched in the bytecode patch step is a Java bytecode having an operation code converted in the static operation code converting step, an operand field of the first higher field address stored in the first storage means and the patched Java bytecode A first field address generation step of generating a second field address by concatenating the first lower field addresses stored in the second field address; And a first data processing step of processing data by accessing a field according to the second field address.

In order to achieve the above object, the Java bytecode conversion method of the present invention comprises: a bytecode patch step of patching a Java bytecode consisting of an operation code field in which an operation code is stored and an operand field in which an operand is stored from a Java class file; If the operation code of the Java bytecode patched in the bytecode patch step is an object field access bytecode for accessing an object field, the field of an object to be accessed by interpreting a constant pool by an operand of the patched bytecode Object field address detection and data processing step of detecting the third field address by combining the offset and the object field address by the first object reference data stored at the top of the stack, and accessing the field according to the third field address to process the data. ; A field offset and object reference data storing step of storing the first object reference data and the field offset in a second storage means; Storing, in a third storage means, a second upper field address composed of upper bits among the bits of the third field address detected in the object field address detection and data processing step, and among the bits of the third field address. A second field address storing step of storing, in the operand field, a second lower field address composed of remaining lower bits except a second upper field address; An object operation code conversion step of converting an operation code stored in the operation code field into an operation code for accessing a new object field preset by a user; If the Java bytecode patched in the bytecode patch step is a Java bytecode having an operation code converted in the object operation code conversion step, the first object reference data stored in the second storage means and the current object stored on the top of the stack. A comparison step of comparing whether the reference data is the same; In the comparing step, if the first object reference data and the current object reference data stored at the top of the stack are the same, the second higher field address stored in the third storage means and the second stored in the operand field of the patched Java byte code Generating a fourth field address by concatenating lower field addresses; A second data processing step of processing data by accessing a field according to the fourth field address; In the comparing step, if the first object reference data and the current object reference data stored at the top of the stack are not the same, an object field address is detected from the current object reference data stored at the top of the stack, and the detected object field address is detected. And a third field address generation step of generating a fifth field address by adding the field offset stored in the second storage means. And a third data processing step of processing data by accessing a field according to the fifth field address.

In the Java bytecode conversion method of the present invention, a field address calculated for bytecodes for static field access and object field access is divided and stored in the operand and storage of the bytecode, and the operation code of the corresponding bytecode is preset. When the bytecode for the field access corresponding to the preset operation code is patched, the data is accessed and processed by the field address by the operand and the data stored in the storage to access the static field and the object field. The field address can be calculated quickly and the performance of the Java application can be improved by reducing the number of source codes required when calculating the field address.

Hereinafter, a Java bytecode conversion method of the present invention will be described in detail with reference to the accompanying drawings.

4A and 4B are flowcharts illustrating a Java bytecode conversion method for processing static fields and a process of processing the same, and FIGS. 5A and 5B illustrate a Java bytecode conversion method for accessing a static field of the present invention. It is a block diagram.

As shown in Figure 4a to 5b Java byte code conversion method of the present invention is a byte code patch step for patching the Java byte code consisting of the operation code field and the operand field stored operand from the Java class file (S110) And, if the opcode of the Java bytecode fetched in the bytecode patch step (S110) is a static field access bytecode for accessing the static field, to interpret and access the constant pool by the operands of the patched bytecode. Detecting the first field address FA1 by combining the field offset of the object and the static field address which is a predetermined value, and detecting the static field address for accessing the field 130 and processing data according to the first field address FA1. Higher order bits of the bits of the first field address FA1 detected in the data processing step S140 and the static field address detection and data processing step S140 A first upper field address FAU1 configured to be stored in the first storage unit 110, and a first lower field bit consisting of remaining bits except for the first upper field address FAU1 among the bits of the first field address FA1 The static field address storing step (S150) of storing the lower field address FAD1 in the operand field 120b, and the operation code for accessing a new static field preset by the user with the operation code stored in the operation code field 120a ( NOPA) Java bytecode that has a static operation code conversion step (S160) to convert to, and the byte code patch step (S110) has an operation code (NOPA) converted in the static operation code conversion step (S160) The second field address FA2 is formed by connecting the first upper field address FAU1 stored in the first storage unit 110 with the first lower field address FAD1 stored in the operand field 120b of the patched Java byte code. According to the first field address generation step (S240) and the second field address (FA2) for generating a Access to fields 130 and consists of a first data processing step (S250) to process the data.

When the first field address FA1 is 32 bits, the first upper field address FAU1 is data consisting of upper 16 bits, and the first lower field address FAD1 is data consisting of lower 16 bits.

The first storage unit 110 is composed of any one of a temporary storage memory, a memory, or registers.

6A and 6B are flowcharts illustrating a Java bytecode conversion method for accessing an object field and a process of processing the same, and FIGS. 7A and 7B are views illustrating a Java bytecode conversion method for accessing an object field of the present invention. It is a block diagram.

6A to 7B, the Java bytecode conversion method of the present invention is a bytecode patch step of patching a Java bytecode consisting of an operation code field in which an operation code is stored and an operand field in which an operand is stored from a Java class file (S310). And, if the operation code of the Java bytecode patched in the bytecode patch step (S310) is an object field access bytecode for accessing the object field, the constant pool is interpreted and accessed by the operands of the patched bytecode. The third field address FA3 is detected by adding the field offset FOi of the object to the object field address based on the first object reference data ODI stored at the top of the stack 240, and the third field address FA3. According to the object field address detection and data processing step (S340) for accessing the field 230 to process the data, the first object reference data (ODi) and the field offset (FOi) The field offset and object reference data storing step (S350) stored in the book 210a, and the upper bits of the bits of the third field address FA3 detected in the object field address detection and data processing step S340 are configured. The second lower field address FAU2 is stored in the third storage unit 210b, and the second lower field consisting of remaining lower bits except for the second upper field address FAU2 among the bits of the third field address FA3. A second field address storage step S360 for storing the field address FAD2 in the operand field 220b, and an operation code for accessing a new object field preset by the user with the operation code stored in the operation code field 220a. Java bytecode having an object operation code conversion step (S390) for converting to NOPB) and an operation code (NOPB) converted from the object operation code conversion step (S390) to the Java bytecode patched at byte code patching step (S310). The first object reference data ODI stored in the second storage unit 210a A comparison step (S440) for comparing whether the current object reference data (COD) stored at the top of the tag 240 is the same, and at the top of the stack 240 and the first object reference data (ODi) in the comparison step (S440) If the current stored object reference data COD is the same, the second higher field address FAU2 stored in the third storage unit 210b and the operand field 220b of the patched Java byte code are stored in the second lower field address FAD2. Second field address generation step S450 of generating a fourth field address FA4 by connecting the second field address FA4, and a second data processing step of accessing the field 230 according to the fourth field address FA4 to process data; If the current object reference data COD stored at the top of the first object reference data ODI and the stack 240 is not the same at S460 and the comparison step S440, the current stored at the top of the stack 240 is not the same. Detects the object field address from the object reference data (COD) of the object and stores the detected object field address in the second storage unit 210a. A third field address generation step S470 of generating the fifth field address FA5 by summing the field offsets FOi, and a method of accessing the field 230 according to the fifth field address FA5 to process data; It consists of three data processing steps (S480).

6A to 7B, the Java byte code conversion method of the present invention stores the first object reference data (ODi) and the field offset (FOi) in a specific location of the second storage unit 210a and stores the second data. A first selection data storage step of storing the first object reference data ODI and the first selection data S1 for selecting the field offset FOi stored in a specific position of the unit 210a in the operand field 220b. S370 and the second upper field address FAU2 for storing the second upper field address FAU2 stored in a specific position of the third storage unit 210b and stored in the specific position of the third storage unit 210b. A second selection data storage step S380 for storing the second selection data S2 in the operand field 220b may be further provided.

When the third field address FA3 is 32 bits, the second upper field address FAU2 is data consisting of upper 16 bits, and the second lower field address FAD2 may be composed of data consisting of lower 16 bits. Or, if the third field address FA3 is 32 bits, the second upper field address FAU2 is data of upper 21 bits, and the second lower field address FAD2 is data of lower 11 bits. The first selection data S1 may be three bits of data, and the second selection data S2 may be two bits of data.

The second and third storage units 210a and 210b may be configured of any one of a temporary storage memory, a memory, or a register.

Operation of the Java byte code conversion method of the present invention according to the above configuration is as follows.

The bytecodes related to Java field access are bytecodes for accessing static fields and bytecodes for accessing object fields. The bytecodes for accessing static fields are 'getstatic' and 'putstatic'. The code is 'getfield' and 'putfield'.

4A to 5B illustrate a Java bytecode conversion method for accessing a static field of the present invention. The operation of the Java bytecode conversion method for accessing a static field of the present invention is as follows.

As shown in FIGS. 4A and 5B, the byte code patching step S110 patches a Java byte code including an operation code field storing an operation code and an operand field storing an operand from a Java class file.

The static field address detection and data processing step S140 is performed when the operation code of the Java bytecode patched in the bytecode patch step S110 is a static field access bytecode for accessing the static field, that is, the operation code is' getstatic 'or' putstatic ', the first field address FA1 is calculated by adding the field offset of the object to be accessed and the static field address, which is a predetermined value, by analyzing the constant pool using operands of the bytecode patched as in the prior art. do. If the program counters to which the bytecodes for static field access are fetched are the same, the calculated field address for static field access always has the same value. The field data FD stored in the field 130 corresponding to the first field address FA1 is accessed according to the operation code of 'getstatic' or 'putstatic' according to the calculated first field address FA1. ) Is stored at the top of the stack 140, or data stored at the bottom of the stack 140 is stored in the field 130 of an address corresponding to the first field address FA1.

The static field address storing step S150 may include a first storage unit configured to form the first upper field address FAU1, which is the upper 16 bits among the bits of the first field address FA1, by any one of a temporary storage memory, a memory, or registers. 110, and the first lower field address FAD1, which is the remaining lower 16 bits of the first field address FA1, is stored in the operand field 120b. That is, since the final field address for accessing the static field is 32 bits, it cannot be stored in the 16-bit operand field, so the first storage unit 110 stores the first upper field address, which is the upper 16 bits of the first field address FA1. (FAU1) is stored, and the first lower field address FAD1, which is the lower 16 bits of the first field address FA1, is stored in the operand field 120b of the patched bytecode 120.

Static operation code conversion step (S160) is a 'getstatic_new' or 'operation code (NOPA) for accessing a new static field preset by the user to the operation code of' getstatic 'or' putstatic 'stored in the operation code field (120a) putstatic_new '.

The first field address generation step S240 is a first storage unit if the Java bytecode patched in the bytecode patch step S110 is a Java bytecode having an operation code NOPA converted in the static operation code conversion step S160. A second field address FA2 is generated by connecting the first upper field address FAU1 stored in 110 with the first lower field address FAD1 stored in the operand field 120b of the patched Java byte code, and The first data processing step S250 approaches the field 130 according to the second field address FA2 and processes the data.

Therefore, when the bytecode for accessing the static field of the present invention is first patched in the bytecode patching step S110, the first field address FA1 is calculated through the constant pool analysis in the same manner as in the prior art, and the data is processed. The field address FA1 is divided and stored in the operand field of the first storage unit 110 and the patched byte code, the operation code field is converted into a new operation code, and then converted into a new operation code in the byte code patching step S110. When the patched bytecode is patched, the first higher field address FAU1 stored in the first storage unit 110 is concatenated with the first lowerfield address FAD1, which is an operand of the operand field 120b of the patched bytecode. By generating the second field address FA2 and processing the data by accessing the field 130 according to the generated second field address FA2, the field address can be quickly calculated. That is, as shown in FIGS. 2A and 2B, in the conventional case, the final field address was calculated by adding the field offset calculated through the constant pool analysis and the detected static field address. However, in the present invention, the program counter is patched with the bytecode. If is equal to the calculated field address for the static field access is the same, the upper 16 bits of the first field address (FA1) that is the same field address is stored in the first storage unit 110, and the lower 16 bits of the operand field ( The second field address FA2, which is the final field address, can be quickly calculated by storing the information stored in the terminal 120b).

If the hardware interpreter is responsible for updating the program counter, the field data FD stored in the field 130 is read and stacked from the second field address FA2 to execute the bytecode instruction of 'getstatic_new' shown in Fig. 5B. Three native codes are required to store the field data (FD) at the top of (140) and update the stack pointer, or 2 if the hardware interpreter is also responsible for updating the stack pointer. Since three source codes are required, the number of source codes required to execute bytecode instructions can be reduced, compared to the conventional ones, thereby improving performance when executing Java applications.

6A to 7B illustrate a Java bytecode conversion method for accessing an object field of the present invention. The operation of the Java bytecode conversion method for accessing an object field of the present invention is as follows.

The bytecodes 'getfield' and 'putfield' for dynamic field access use static field access because object reference data at the top of stack 240 may vary even if the program counters being patched are identical. It should be handled differently than the bytecode for.

As shown in FIGS. 6A and 7A, the byte code patching step S310 patches a Java byte code including an operation code field in which an operation code is stored and an operand field in which an operand is stored, from a Java class file. In the object field address detection and data processing step S340, when the operation code of the Java byte code patched in the byte code patch step S310 is 'getfield' or 'putfield', which is an object field access byte code for accessing an object field, In the same way as in the conventional method, an object field based on a field offset (FOi) of an object to be accessed by analyzing a constant pool by an operand of a patched bytecode and a first object reference data (ODi) stored at the top of the stack 240. The sum of the addresses detects the third field address FA3, and accesses the field 230 according to the third field address FA3 to process data.

The field offset and object reference data storing step (S350) stores the first object reference data (ODi) and the field offset (FOi) in the second storage unit 210a, and the second field address storing step (S360) is an object field. The second upper field address FAU2 including upper bits among the bits of the third field address FA3 detected in the address detection and data processing step S340 is stored in the third storage unit 210b, and the third storage unit 210b stores the third upper field address FAU2. The second lower field address FAD2 including the remaining lower bits except the second upper field address FAU2 among the bits of the field address FA3 is stored in the operand field 220b.

If the third field address FA3 is 32 bits, the second upper field address FAU2 is data consisting of the upper 16 bits, and the second lower field address FAD2 is the lower 16 bits, similar to the static field access. The first object reference data (ODi), the field offset (FOi), and the second upper field address (1) stored in the second storage unit 210a and the third storage unit 210b, respectively. According to the number of FAU2), the sizes of the bits of the second upper field address FAU2 and the second lower field address FAD2 are different. For example, as shown in FIG. 6A, the number of entries that can be stored in the second storage 210a is set to eight, and the number of entries that can be stored in the third storage 210b is set. In the case of setting the number to four, the number of these entries is, of course, a value determined by the user, and eight field offsets FOi and one first object reference data ODi stored in the second storage 210a are stored. In order to determine the entry of the stored location, the first selection data S1 composed of 3 bits is required, and the third upper field address FAU2 stored in the third storage unit 210b is three. Requires second selection data S2 consisting of two bits to determine the entry of the location to be stored. In this case, the first and second selection data S1 and S2 must be stored in the operand field 120b. In the operand field 120b, only 11 bits are excluded except the first and second selection data S1 and S2 which are 5 bits. Can to be stored second sub-field address (FAD2) is a third field, and address data composed of the lower 11 bits of the (FA3), the second field is the top address (FAU2) is made up of data consisting of the upper 21 bits.

The first selection data storing step S370 stores the first object reference data ODI and the field offset FOi at a specific position of the second storage unit 210a, and stores the first object reference data ODI and the field offset FOi at a specific position of the second storage unit 210a. The first selection data S1 for selecting the stored first object reference data ODI and the field offset FOi is stored in the operand field 220b, and the second selection data storing step S380 is performed in the second upper field. Second selection data S2 for storing the address FAU2 at a specific location of the third storage unit 210b and for selecting a second higher field address FAU2 stored at the specific location of the third storage unit 210b. ) Is stored in the operand field 220b.

Object operation code conversion step (S390) is the operation code 'getfield' or 'putfield' stored in the operation code field 220a 'getfield_new' or 'operation code (NOPB) for accessing a new object field preset by the user convert it to putfield_new '.

As shown in FIGS. 6B and 7B, the comparing step S440 is a Java byte having the operation code NOPB converted in the object operation code conversion step S390 of the Java bytecode patched in the byte code patch step S310. If it is a code (S420), that is, when patching the same program counter as the program counter having the operation code (NOPB) converted in the object operation code conversion step (S390), the first object reference stored in the second storage unit (210a) The data ODI and the current object reference data COD stored at the top of the stack 240 are compared with each other.

 If the Java bytecode patched in the bytecode patch step S310 is not the Java bytecode having the operation code NOPB converted in the object operation code conversion step S390, the Java bytecode is performed according to the same method as the conventional bytecode conversion method. (S430).

If the first object reference data (ODi) and the current object reference data (COD) stored on the top of the stack 240 is the same in the comparison step (S440), the final field address is the object field address detection and data processing step (S340) Since the second field address FA3 is identical to the third field address FA3 detected in the second field address generation step S450, the second higher field address FAU2 composed of 21 bits stored in the third storage unit 210b and the patched Java field. An operand field 220b of the bytecode is connected to the second subfield address FAD2 having 11 bits stored therein to generate a fourth field address FA4, and the second data processing step S460 generates a fourth field address. According to FA4, the field 230 is approached to process data. That is, if the first object reference data (ODi) and the current object reference data (COD) are the same in the comparison step (S440), the upper field stored in the storage unit in the same manner as the Java byte code conversion method for accessing the static field of FIG. The final field address for field access is created by linking with the subfield address stored in the address and operand fields.

In the third field address generation step S470, the first object reference data ODI stored in the second storage unit 210a and the current object reference data COD stored at the top of the stack 240 may be compared in operation S440. If is not the same, the last field address of the bytecode having the patched converted opcode for accessing the object field and the third field address FA3 detected in the object field address detection and data processing step S340 is different. In order to generate the fifth field address FA5, which is the final field address, the object field address is detected from the current object reference data COD stored at the top of the stack 240, and the detected object field address and the second storage unit ( The fifth field address FA5 is generated by adding the field offsets FOi stored in 210a.

The third data processing step S480 approaches the field 230 according to the fifth field address FA5 to process data.

In the comparison step S440 and the third field address generation step S470, the first object reference data ODI and the field offset FDi stored in the second storage unit 210a are taken out from the second storage unit 210a, respectively. In this case, it is determined according to the logical value of the data of the first selection data S1 stored in the operand field 220b of the patched bytecode. That is, when the logical value of the first selection data is 011, the first object reference data OD4 and the field offset FD4 stored in the fourth entry of the second storage unit 210a are extracted from the second storage unit 210a. Process.

As described above, when the second upper field address FAU2 of the third field address FA3 stored in the third storage unit 210b is retrieved from the third storage unit 210b in the second field address storage step S360. The second higher field address FAU2 stored in the position of the entry determined according to the data logical value of the second selection data S2 is obtained. For example, if the second selection data S2 is 10, the second lower field address stored in the operand field 220b is obtained by obtaining the second higher field address FAU2b stored in the third entry of the third storage unit 210b. In connection with FAD2, a fourth field address FA4, which is the final field address, is generated.

The second storage unit 210a and the third storage unit 210b may be configured of any one of a temporary storage memory, a memory, or a register.

Accordingly, the Java bytecode conversion method for accessing the object field of the present invention shown in FIGS. 6A to 7B is presently present at the top of the stack 240 when processing the bytecode for accessing the object field fetched from a specific program counter. If the object reference data (COD) and the first object reference data (ODi) stored in the second storage unit 210a is the same in the field offset and object reference data storage step (S350) of the second stored in the patched operand field By connecting the lower field address FAD2 and the second upper field address FAU2 stored in the third storage unit 210b, the fourth field address FA4, which is the final field address for field access, can be quickly generated. If the number of source codes required for this can be reduced, and the current object reference data (COD) and the first object reference data (ODi) are not the same, the field offset set (FDi) stored in the second storage unit 210a. To the current object reference data (COD) Combining the detected object field emitter address can easily generate the final address field of a fifth address field (FA5) for field access.

The Java bytecode conversion method of the present invention may be implemented with the Java bytecode conversion method for accessing the static field of FIGS. 4A and 4B and the Java bytecode conversion method for accessing the object field of FIGS. 6A and 6B. Field discrimination to determine whether the patched bytecode is for object field access or static field access as shown in FIGS. 1 and 2B after patching the bytecode in the bytecode patching step (S110, S210, S310, S410) More steps are needed. In this case, the first storage unit 110 and the second storage unit 210a do not need to be configured separately, but may be configured as one storage unit.

A wava virtual machine made by targeting a portable device with a hardware interpreter embedded in a processor based on the conventional Java bytecode conversion method according to FIGS. 2A and 2B and the Java bytecode conversion method according to the present invention. In case of using Waba Virtual Machine, the number of required source codes is compared as follows.

 Bytecode getstatic, the number of source codes required the number of source codes required for putstatic For getfield, the number of source codes required For putfield, the number of source codes required Conventional case 37 38 59 61 In the case of the present invention 3 3 23 26

In Table 1, in order to execute the byte codes of 'getfield' and 'putfield' for accessing the object field, the second storage unit 210a is accessed to present the first object reference data ODI and the top of the stack 240. It is necessary to compare whether the object reference data (COD) of is the same, it can be seen that a lot of source code is required compared to the case of performing 'getstatic' and 'putstatic' bytecode for accessing the static field, Java byte of the present invention It can be seen that the number of source codes required is significantly reduced compared to the conventional case when performing bytecode by the code conversion method.

Therefore, the Java bytecode conversion method of the present invention can reduce the number of source codes required to generate field addresses for static field access and object field access, thereby improving performance when executing a Java application. have.

1 is a flowchart illustrating a process of processing Java bytecode in a conventional field access method.

2A and 2B are flowcharts illustrating a Java bytecode conversion method for accessing a conventional field;

3 is a block diagram illustrating a conventional Java bytecode conversion method of FIGS. 2A and 2B;

4A and 4B are flowcharts illustrating a Java bytecode conversion method and a process of processing the same according to the present invention for dynamic field access;

5A and 5B are diagrams for describing a Java bytecode conversion method of the present invention for dynamic field access;

6A and 6B are flowcharts illustrating a method of processing Java bytecode conversion and processing the same for accessing an object field;

7A and 7B are diagrams illustrating a Java bytecode conversion method of the present invention for accessing an object field.

Claims (9)

A bytecode patch step (S110) of patching a Java bytecode composed of an operation code field in which an operation code is stored and an operand field in which an operand is stored from a Java class file; If the operation code of the Java bytecode patched in the bytecode patch step is a static field access bytecode for accessing a static field, the field of an object to be accessed by interpreting a constant pool by an operand of the patched bytecode A static field address detection and data processing step of detecting a first field address by adding an offset and a static field address which is a predetermined value, and accessing a field according to the first field address to process data; Storing a first upper field address composed of upper bits among the bits of the first field address detected in the static field address detection and data processing step S140 in a first storage means, and storing the bits of the first field address. A static field address storing step (S150) of storing a first lower field address composed of remaining lower bits except for a first upper field address among the operand fields; A static operation code conversion step (S160) of converting an operation code stored in the operation code field into an operation code for accessing a new static field preset by a user; If the Java bytecode patched in the bytecode patch step is a Java bytecode having an operation code converted in the static operation code converting step, an operand of a first higher field address stored in the first storage means and a patched Java bytecode Generating a second field address by concatenating the first subfield address stored in the field (S240); And And a first data processing step (S250) for processing data by accessing a field according to the second field address. The method of claim 1, wherein when the first field address is 32 bits, the first upper field address is data consisting of upper 16 bits, and the first lower field address is data consisting of lower 16 bits. Java bytecode conversion method. The method of claim 1, wherein the first storage means is any one of a temporary storage memory, a memory, and registers. A bytecode patch step (S310) of patching a Java bytecode consisting of an operation code field in which an operation code is stored and an operand field in which an operand is stored from a Java class file; When the operation code of the Java byte code patched in the byte code patch step S310 is an object field access byte code for accessing an object field, the constant pool is interpreted and accessed by an operand of the patched byte code. Detects the third field address by adding the field offset of the object and the object field address by the first object reference data stored at the top of the stack, and detects the object field address that processes the data by accessing the field according to the third field address. And a data processing step (S340); A field offset and object reference data storing step of storing the first object reference data and the field offset in a second storage means (S350); Storing a second upper field address composed of upper bits among the bits of the third field address detected in the object field address detection and data processing step S340, and storing the bits of the third field address. A second field address storing step (S360) of storing a second lower field address including remaining lower bits except for a second upper field address in the operand field; An object operation code conversion step (S390) of converting an operation code stored in the operation code field into an operation code for accessing a new object field preset by a user; If the Java bytecode patched in the bytecode patch step is a Java bytecode having an operation code converted in the object operation code conversion step (S390), the first object reference data stored in the second storage means and stored on the top of the stack A comparing step S440 of comparing whether current object reference data is the same; If the first object reference data and the current object reference data stored at the top of the stack are the same in the comparison step (S440), the second higher field address stored in the third storage means and the operand field of the patched Java byte code are stored. Generating a fourth field address by concatenating the stored second subfield addresses (S450); A second data processing step (S460) of accessing a field according to the fourth field address to process data; If the first object reference data and the current object reference data stored at the top of the stack are not the same in the comparison step (S440), an object field address is detected from the current object reference data stored at the top of the stack and detected. A third field address generation step (S470) of generating a fifth field address by adding an object field address and a field offset stored in the second storage means; And And a third data processing step (S480) for processing data by accessing a field according to the fifth field address. The method of claim 4, wherein the first object reference data and the field offset are stored at a specific position of the second storage means, and the first object reference data and the field offset stored at the specific position of the second storage means are selected. And a first selection data storing step (S370) of storing first selection data in the operand field. 6. The method of claim 5, wherein the second higher field address is stored at a specific position of the third storage means, and the second selection data for selecting the second higher field address stored at the specific position of the third storage means is stored. And a second selection data storage step (S380) for storing in the operand field. The method of claim 4, wherein when the third field address is 32 bits, the second upper field address is data consisting of upper 16 bits, and the second lower field address is data consisting of lower 16 bits. Java bytecode conversion method. 7. The method of claim 6, wherein when the third field address is 32 bits, the second upper field address is data consisting of upper 21 bits, and the second lower field address is data consisting of lower 11 bits. The first selection data is data consisting of three bits, and the second selection data is data consisting of two bits. The method of claim 4, wherein the second and third storage means are any one of a temporary storage memory, a memory, and registers.

Images