JP5090279B2 - Program conversion system - Google Patents

Description

  The present invention relates to a system for converting a program, and more particularly to a system and a conversion method for encoding a byte code of another language on a byte code of a specific language.

  When a computer system is operated, a plurality of programs written in different programming languages may be executed in cooperation with each other. For example, there is a case where a program written in PHP (PHP: Hypertext Preprocessor) or the like is executed on a platform by Java (registered trademark of Sun Microsystems, Inc.).

  In order to realize a language processing system that operates effectively in various aspects, it is desirable to properly use a plurality of such machine language codes. However, a processing system that understands one machine language code expression usually cannot understand another machine language code expression as it is. Therefore, conventionally, a device for executing another machine language code from a processing system that executes one machine language code has been devised.

  Patent Document 1 discloses a processing system in which two types of binary representation programs are provided in one application. According to this prior art, since the application can execute a plurality of different types of machine language codes, the machine language codes as described above can be used properly.

  Non-Patent Document 1 discloses a program conversion method called subroutine threading. According to this prior art, for example, the Java byte code is configured so that each instruction of the PHP byte code corresponds to a subroutine (method) call on the Java byte code, and the method to be called is implemented in Java. By using this subroutine threading, it is possible to read PHP language semantics from the Java bytecode of the compilation result.

US Pat. No. 5,432,937 C. J. Cheney, "A Nonrecursive List Compacting Algorithm", Communications of the ACM 13 (11), 1970.

As described above, a device for executing another machine language code from a processing system that executes one machine language code has been conventionally performed.
However, when dealing with two types of binary representation programs in a processing system provided in one application, there are the following problems. For example, when there are two types of processing systems, both of the processing systems are read into the execution system. For this reason, binary data corresponding to each processing system has to be prepared, and the size of the program has increased. The plurality of binary data prepared at this time are independent and different expressions. For this reason, whether or not the property found by examining a predetermined byte code is realized by other byte codes can be understood only by examining other byte codes. Therefore, a completely independent verification operation is required for each binary data.

  Further, the technique based on subroutine threading has a problem that the processing cost for reading a subroutine is high. This is intended only for subroutine threading to be executed directly on a platform (eg, Java virtual machine) in the first place, and instructions for other languages (eg, PHP language) embedded therein This is because it is not designed to read the semantics.

  An object of the present invention is to solve these problems, and to provide a system and a program conversion method for generating a program to be executed efficiently by encoding a plurality of different types of byte codes on one file.

  In order to achieve the above object, the present invention is realized as the following system. The system encodes a second language byte code on a first language byte code to generate a class file of the first language byte code, the second language byte code And a class having a data structure for actually generating the byte code of the first language based on the result of the pre-processing and holding a value referred to from the byte code of the method call A coding processing unit for generating a file; The preprocessing unit stores, in the temporary storage unit, an area used by a virtual bytecode instruction that is a bytecode of the second language that has been rewritten into a format executable by the bytecode processing system of the first language. This virtual bytecode is secured in a predetermined location for each instruction of the second language bytecode in the data structure held, and each instruction in the bytecode of the second language is converted into a virtual bytecode. Is stored in the temporary storage means. The encoding processing unit generates a bytecode class file of the first language including the data structure and virtual bytecode held in the temporary storage means.

This system can also be realized as a configuration further including an execution unit that executes the generated class file in a form different from the execution form of the normal first language bytecode.
Preferably, the execution unit holds information indicating a correspondence relationship between the byte code instruction of the second language and a place on the data structure used by the predetermined instruction in the storage unit, and this information Based on the above, the contents of the virtual bytecode are recognized from the location on the data structure without reading many parts of the class file.

In the above system, more specifically, the encoding processing unit encodes the virtual bytecode as a bytecode method of the first language.
In addition, the encoding processing unit records information indicating the position of the data and the method necessary for executing the virtual bytecode in the data structure. Then, the execution unit decodes and executes the class file based on the information indicating the position of the data and the method recorded in the data structure, omitting the decoding of the contents unnecessary for the execution of the virtual bytecode.

  The present invention is also realized as the following method. This method is a program conversion method for encoding a byte code of a second language on a byte code of a first language to generate a class file of the byte code of the first language. The class file has a data structure that holds a value referenced from the byte code of the method call, and the byte code of the second language that has been rewritten into a format that can be executed by the processing system of the first language byte code Securing a region used by a virtual bytecode instruction that is a predetermined location for each bytecode instruction of the second language in the data structure held in the temporary storage means; Converting each instruction in the language bytecode into a virtual bytecode and holding the virtual bytecode in a temporary storage means; and temporary storage It includes holding data structures stage, and generating the class files bytecode first language encodes the virtual byte code as a method, a.

  Furthermore, the present invention is also realized as a program for controlling a computer to realize each function in the above system and a program for executing a process corresponding to each step in the above method. This program is provided by being stored and distributed in an optical disk, magnetic disk, semiconductor memory, or other recording medium, or distributed via a network.

  According to the present invention configured as described above, it is possible to provide a system and a program conversion method for encoding a plurality of different types of byte codes on one file and generating a program to be executed efficiently.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.
The present invention can be applied to a program written in a programming language having certain features (described later). In this embodiment, Java byte code and PHP byte code are encoded on one file. This will be described as an example. Specifically, the PHP byte code is encoded into a Java byte code as a virtual byte code (described later).

<System configuration>
FIG. 1 is a diagram showing an overall configuration of a system to which the present embodiment is applied.
The system shown in FIG. 1 is realized by a computer such as a personal computer. This system includes a conversion unit 100 that compiles a source code in which a PHP script is described to generate a Java bytecode, and an execution unit 200 that executes the generated bytecode.

  The conversion unit 100 is a compiler, and includes a preprocessing unit 110 that generates a virtual bytecode, and a coding processing unit 120 that generates a class file of a Java bytecode incorporating the virtual bytecode. Here, the virtual bytecode is a PHP bytecode encoded as a method call on the Java bytecode, in other words, converted into a form that can be executed as it is by the Java virtual machine. The virtual bytecode is composed of a virtual instruction and a virtual constant value (constant value).

  The execution unit 200 is a Java virtual machine, an execution system of PHP bytecode, or an execution system having the properties of both. When the execution unit 200 is a Java virtual machine, it is executed as a normal Java bytecode. On the other hand, when the execution system is a PHP bytecode, the execution unit 200 executes the bytecode according to the data structure unique to the bytecode generated by the conversion unit 100, as will be described in detail later. The implementation of the execution unit 200 may be an interpreter or a JIT (Just In Time) compiler. A plurality of implementations may coexist.

FIG. 2 is a diagram illustrating a hardware configuration example of a computer that realizes the program processing apparatus according to the present embodiment.
The computer 10 shown in FIG. 2 includes a CPU (Central Processing Unit) 10a that is a calculation means, a main memory 10c that is a storage means, and a magnetic disk device (HDD: Hard Disk Drive) 10g. In addition, a network interface card 10f for connecting to an external device via a network, a video card 10d and a display device 10j for performing display output, and an audio mechanism 10h for performing audio output are provided. Furthermore, an input device 10i such as a keyboard or a mouse is provided.

  As shown in FIG. 2, the main memory 10c and the video card 10d are connected to the CPU 10a via the system controller 10b. The network interface card 10f, the magnetic disk device 10g, the sound mechanism 10h, and the input device 10i are connected to the system controller 10b via the I / O controller 10e. Each component is connected by various buses such as a system bus and an input / output bus. For example, the CPU 10a and the main memory 10c are connected by a system bus or a memory bus. Between the CPU 10a and the magnetic disk device 10g, the network interface card 10f, the video card 10d, the audio mechanism 10h, the input device 10i, etc., PCI (Peripheral Components Interconnect), PCI Express, serial ATA (AT Attachment) , USB (Universal Serial Bus), AGP (Accelerated Graphics Port) and other input / output buses.

  Note that FIG. 2 merely exemplifies a hardware configuration of a computer suitable for application of the present embodiment, and it is needless to say that each actual server is not limited to the illustrated configuration. For example, instead of providing the video card 10d, only the video memory may be mounted and the CPU 10a may process the image data. Further, the audio mechanism 10h may be provided as a function of a chip set that constitutes the system controller 10b and the I / O controller 10e without being an independent configuration. In addition to the magnetic disk device 10g, an auxiliary storage device may be provided with a drive using various optical disks and flexible disks as media. A liquid crystal display is mainly used as the display device 10j, but any other type of display such as a CRT display or a plasma display may be used.

  In the system shown in FIG. 1, the conversion unit 100 and the execution unit 200 are realized by the CPU 10 a executing the program read into the main memory 10 c in the computer shown in FIG. 2, for example. Temporary files and the like generated during the processing of the conversion unit 100 and the execution unit 200 are held in a work area or the like of the main memory 10c.

<Data structure of byte code>
FIG. 3 is a diagram showing the data structure of the Java byte code.
The byte code class file of the present embodiment generated by the conversion unit 100 is the same as an ordinary Java byte code class file as an overall configuration. That is, as shown in FIG. 3, a portion called a header 301, a constant pool 302, class information 303, a field 304, a method 305, and an attribute 306 is included. The method 305 includes a Java instruction, a virtual instruction that is a PHP instruction, and a constant pool inside the PHP that is used for the virtual instruction.

  As described above, in this embodiment, a PHP byte code is encoded as a virtual byte code into a Java byte code. More specifically, the virtual bytecode is encoded as an index (index number) in the constant pool 302 that contains an invocative (0xb8) instruction and a constant value indicating a method. For example, when considering a virtual bytecode for PHP language, a virtual instruction called ADD for adding PHP objects is a method call to the static method add () of the Virtual Opcodes class. The constant pool 302 is a data structure that holds a value that is referred to from the byte code of the method call.

The actual byte sequence is

0xb8 (invokestatic)
0x00 (higher byte of 5, index for the constant pool)
0x05 (lower byte of 5, index for the constant pool)

It becomes 3 bytes. However, it is assumed that the constant pool 302 is as shown in FIG. As a result, as a Java byte code, com. ibm. This means that a static method called void add (Runtime) of the Virtual Opcodes class is called. Note that, depending on the implementation, instead of the invokative (0xb8) instruction, the invokevirtual (0xb6), invokeinterface (0xb9), invokespecial (0xb7), or the like may be used.

An execution context (Runtime) is passed as an argument of the method. When a virtual instruction that changes the state of the virtual machine is implemented as a Java method, it is implemented as an operation on this execution context object. Here, the state of the virtual machine includes contents of virtual storage devices such as registers, stacks, and heaps in the PHP byte code, and input / output in a broad sense. Therefore, changing the state of the virtual machine means that, for example, access to an external input / output or loading / unloading to / from a stack is performed. Specifically, for example, an instruction called ADD
-Take two values from the stack.
・ Put the value of the calculation result on the stack.
This causes a change in the state of the virtual machine. Note that this may be omitted for instructions that do not require an execution context.

  An actual Java virtual machine branch instruction is used to encode an unconditional branch instruction of a virtual bytecode or a conditional branch instruction. Specifically, goto (0xa7) is used for the unconditional branch, and ifne (0x9a) or ifeq (0x99) is used for the conditional branch. Further, depending on the implementation form, a branch combined with a multi-condition branch instruction tableswitch (0xaa) and lookupswitch (0xab) is also conceivable.

  As a constant of the virtual bytecode, a static field and a read static (getstatic (0xb2)) are used. Depending on the implementation, it may be realized by using an instance field and getfield (0xb4) that is read from the instance field.

<Constant pool data structure>
Next, the data structure of the constant pool in this embodiment will be described.
FIG. 5 is a diagram illustrating a part of an operation code (Opcode) of PHP.
As shown in FIG. 5, in the present embodiment, as many consecutive numbers (IDs) as possible are assigned to each operation code of the virtual bytecode, and this number is assumed to be shared among users. The start of the number may be determined so as not to become too large, or information such as an offset may be passed separately so that the number can be adjusted flexibly for each class file.

FIG. 6 is a diagram showing an example of a constant pool according to the present embodiment configured corresponding to the opcode ID of FIG.
As shown in FIG. 6, in this embodiment, method information (Method_info) for designating a method corresponding to each virtual instruction is placed at a position where the corresponding ID is an index in the constant pool. In this way, by determining the placement in the constant pool according to the contents of the virtual instruction, it is only necessary to read the constant pool entry index included in the 3 bytes following the invocative (without reading the method information itself). ), The contents of the virtual instruction represented by the series of bytecodes can be understood.

  Various methods are conceivable as a method for adjusting such a constant pool. The simple way is to keep all constants that specify virtual instructions fixed and not used for other purposes. Further, in order to use the constant pool somewhat efficiently, the entry of the constant pool corresponding to the unused virtual instruction may be opened for other uses.

<Function of conversion unit>
Next, functions of the preprocessing unit 110 and the encoding processing unit 120 of the conversion unit 100 will be described.
FIG. 7 is a flowchart showing the flow of processing by the conversion unit 100.
In the operation example shown in FIG. 7, a component (To-Do list) for temporarily storing a constant pool, a method definition, a field definition, and the like is prepared. This component is realized by, for example, the main memory 10c and the cache memory of the CPU 10a shown in FIG.
Referring to FIG. 7, first, the preprocessing unit 110 of the conversion unit 100 looks at the entire program to be converted and reserves an arrangement location in the constant pool for each virtual instruction (step 701).

  Next, the pre-processing unit 110 performs byte code generation processing for each virtual instruction, and places the generated byte code in a location that is not yet reserved in the constant pool (step 702). At this time, when the virtual instruction takes a virtual constant value, a field (name) for encoding the virtual instruction is assigned, and the virtual instruction value is put in the To-Do list together with the virtual constant value.

  After the above operation, the preprocessing unit 110 generates the fields assigned in step 702 and codes for initializing them, and puts them in the To-Do list (step 703). Then, the encoding processing unit 120 writes out all the contents held in the To-Do list as Java bytecodes (step 704). In the written Java bytecode, information indicating the position of the data required for execution and the method (called this offset value) is recorded as a constant constant value of constant_integer_info type in the cp_info array in the constant pool. The The information indicated by the offset value includes the start position of the body part (Code attribute information) of the method in which the virtual instruction sequence is encoded, the start position of the recorded content of the constant pool that needs to be read, and the constant pool to be read -Three of the index of the entry.

FIG. 8 is a flowchart showing the contents of the bytecode generation process of FIG.
Referring to FIG. 8, the preprocessing unit 110 first determines whether or not the virtual instruction takes a virtual constant value (step 801). When the virtual constant value is not taken (No in Step 801), the preprocessing unit 110 generates byte code “alload 1” related to the runtime context (Step 804).

  On the other hand, when the virtual instruction takes a virtual constant value (Yes in step 801), the preprocessing unit 110 adds information of {field, value} to the To-Do list (step 802). Then, after the byte code “getstatic” relating to the added field is generated (step 803), the byte code “alload 1” is generated (step 804).

  Next, the preprocessing unit 110 assigns the generated bytecode to a reserved place in the constant pool index (step 805). Then, a bytecode “invokestatic” is generated (step 806). The index of the Methodref constant pool entry added to the bytecode “invokestatic” is specified according to the type of the encoded virtual instruction. Therefore, by looking at the bytecode generated in step 806, the contents of the virtual instruction can be understood without actually reading the Methodref constant pool entry and decoding the contents.

The byte code generation processing of FIG. 8 will be further described with a specific example of virtual instructions.
PHP source code

echo “Hello World ¥ n”;

On the other hand, the virtual instruction is as follows.

PUSH “Hello World ^ n”
ECHO

When this virtual instruction is processed according to the procedure shown in FIG.

First, if “PUSH“ Hello World ^ n ”” is processed, the result in Step 801 is Yes.

{Field, value} = {“constVal0”, “Hello World \ n”}

Is added to the To-Do list. In step 803, the byte code

getstatic “constVal0”

Is generated, and in step 804, a bytecode is generated.

aload 1

Is generated.

Thereafter, in step 805, an index of Methodref constant pool entry (information called VirtualOpcodes.push (PHPValue, Runtime)) for the push opcode is obtained. Here, “20” is assumed. In step 806, the byte code

Invokestatic 20

Is generated.

Next, when processing is performed for “ECHO”, the result in Step 801 is No.

aload 1

Is generated. In step 805, an index of Methodref constant pool entry (information called VirtualOpcodes.echo (Runtime)) for the ECHO opcode is obtained. Here, “30” is assumed. In step 806, the byte code

Invokestatic 30

Is generated.

<Function of the execution unit>
Next, functions of the execution unit 200 will be described.
The execution unit 200 according to the present embodiment omits unnecessary constant pool decoding when it is not necessary to perform verification such as when bytecode or virtual bytecode has already been verified. By reading the constant pool entries and bytecodes necessary for program execution, high-speed reading is realized.

FIG. 9 is a flowchart showing the flow of processing of the execution unit 200 when bytecode verification need not be performed.
Referring to FIG. 9, the execution unit 200 first skips the first 8 bytes of the program (step 901). As a result, the Java byte code header 301 shown in FIG. 3 is skipped.

  Next, the execution unit 200 reads the number of constant pool entries (step 902), and further reads the offset value recorded in the constant pool (step 903). Next, the execution unit 200 skips unnecessary constant pool entries such as Methodref for virtual instructions using the offset value read in Step 903 (Step 904). The remaining constant pool entry is read and decoded (step 905). Thereafter, the execution unit 200 skips to the beginning of the virtual instruction sequence (run ()) (actually, previous method information) (step 906), and reads the subsequent virtual instruction sequence (step 907).

  As described above, in this embodiment, when it is not necessary to perform bytecode verification on the class file generated by the conversion unit 100, the execution unit 200 reads and decodes all the class files. Rather than skipping unnecessary parts using the offset value, only the necessary parts are read and decoded. Therefore, it is possible to increase the processing speed of the execution unit 200.

  As mentioned above, although this embodiment was described, the technical scope of this invention is not limited to the range as described in the said embodiment. For example, in the above-described embodiment, a case has been described in which a PHP byte code is encoded into a Java byte code to generate a class file. However, it goes without saying that the applied language is not limited to Java and PHP. Assuming that the second byte code is encoded on the first byte code, the first byte code holds a value referenced from the byte code of the method call, such as a Java constant pool. The present embodiment can be applied to any language that has a data structure and this data structure is located at a position (near the top) that is read as early as possible in the entire class file. In addition, it is clear from the description of the scope of the claims that various modifications or improvements added to the above embodiment are also included in the technical scope of the present invention.

It is a figure which shows the whole structure of the system to which this embodiment is applied. It is a figure which shows the hardware structural example of the computer which implement | achieves the program processing apparatus of this embodiment. It is a figure which shows the data structure of a Java bytecode. It is a figure which shows the structural example of the constant pool in the bytecode of FIG. It is a figure which illustrates a part of PHP opcode (Opcode). It is a figure which shows the example of the constant pool by this embodiment comprised corresponding to the opcode ID of FIG. It is a flowchart which shows the flow of the process by the conversion part of this embodiment. It is a flowchart which shows the content of the bytecode production | generation process of FIG. It is a flowchart which shows the flow of a process of the execution part of this embodiment in the case where it is not necessary to verify a bytecode.

Explanation of symbols

10a ... CPU, 10c ... main memory, 100 ... conversion unit, 110 ... preprocessing unit, 120 ... coding processing unit, 200 ... execution unit

Claims (11)

In a system for encoding a byte code of a second language on a byte code of a first language to generate a class file of the byte code of the first language,
A preprocessing unit for performing preprocessing on the bytecode of the second language;
An encoding processing unit that actually generates a byte code of the first language based on a result of the preprocessing, and generates a class file having a data structure that holds a value referenced from the byte code of the method call; With
The pre-processing unit is
An area used by a virtual bytecode instruction that is a bytecode of the second language that has been rewritten into a format executable by the bytecode processing system of the first language is held in a temporary storage unit Secure in a predetermined place for each byte code instruction of the second language in the data structure;
Converting each instruction in the byte code of the second language into the virtual byte code, and holding the virtual byte code in the temporary storage means;
The encoding processing unit
Generating a bytecode class file of the first language including the data structure held in the temporary storage means and the virtual bytecode;
system.   The system according to claim 1, wherein the encoding processing unit encodes the virtual bytecode as a method of a bytecode of the first language.   The system according to claim 2, wherein the encoding processing unit records information indicating a position of data and a method necessary for execution of the virtual bytecode in the data structure.   The system according to claim 1, wherein the byte code of the first language is a Java (registered trademark) byte code, and the data structure is a constant pool used in a Java virtual machine.   5. The system of claim 4, wherein the second language bytecode is a PHP bytecode. In a system that encodes a byte code of a second language on a byte code of a first language, generates a class file of the byte code of the first language, and executes the class file,
A preprocessing unit for performing preprocessing on the bytecode of the second language;
An encoding processing unit that actually generates a byte code of the first language based on a result of the preprocessing, and generates a class file having a data structure that holds a value referenced from the byte code of the method call; ,
An execution unit that executes the class file generated by the encoding processing unit,
The pre-processing unit is
An area used by a virtual bytecode instruction that is a bytecode of the second language that has been rewritten into a format executable by the bytecode processing system of the first language is held in a temporary storage unit Secure in a predetermined place for each byte code instruction of the second language in the data structure;
Converting each instruction in the byte code of the second language into the virtual byte code, and holding the virtual byte code in the temporary storage means;
The encoding processing unit
Including the data structure held in the temporary storage means, and generating a bytecode class file of the first language in which the virtual bytecode is encoded as a method;
system. The execution unit is
Holding information indicating a correspondence relationship between the byte code instruction of the second language and a place on the data structure used by the predetermined instruction in a storage unit;
The system according to claim 6, wherein the content of the virtual bytecode is recognized from a location on the data structure based on the information. The encoding processing unit records, in the data structure, information indicating the position of data and a method necessary for execution of the virtual bytecode,
The execution unit decodes and executes the class file based on information indicating the position of the data and the method recorded in the data structure, omitting decoding of contents unnecessary for execution of the virtual bytecode. The system according to claim 7, wherein: In a system that encodes a PHP byte code into a Java (registered trademark) byte code, generates a class file of the Java byte code, and executes the class file,
A preprocessing unit for performing preprocessing on the PHP bytecode;
An encoding processing unit that actually generates the Java bytecode based on the result of the preprocessing and generates a class file;
An execution unit that executes the class file generated by the encoding processing unit,
The pre-processing unit is
An area used by a virtual bytecode instruction, which is a rewrite of the PHP bytecode into a format executable by the Java bytecode processor, in the constant pool held in the temporary storage means Secure in a predetermined place for each code instruction,
Converting each instruction in the PHP bytecode into the virtual bytecode, holding the virtual bytecode in the temporary storage means,
The encoding processing unit
Including the constant pool held in the temporary storage means, and generating a class file of the Java bytecode in which the virtual bytecode is encoded as a method;
In the constant pool, record data indicating the position of data and method necessary for execution of the virtual bytecode,
The execution unit is
Information indicating the correspondence between the instruction of the PHP bytecode and the location on the constant pool used by the instruction is determined in a storage unit;
Based on the information, the content of the virtual bytecode is recognized from a location on the constant pool,
Based on the data and the information indicating the position of the method recorded in the constant pool, the decryption and execution of the class file is performed by omitting the decryption of contents unnecessary for the execution of the virtual bytecode.
system. In a program conversion method for encoding a byte code of a second language on a byte code of a first language to generate a class file of the byte code of the first language,
The bytecode class file of the first language has a data structure that holds a value referenced from the bytecode of the method call,
An area used by a virtual bytecode instruction that is a bytecode of the second language that has been rewritten into a format executable by the bytecode processing system of the first language is held in a temporary storage unit Securing at a predetermined location for each byte code instruction of the second language in the data structure;
Converting each instruction in the byte code of the second language into the virtual byte code, and holding the virtual byte code in the temporary storage means;
Generating a bytecode class file of the first language including the data structure held in the temporary storage means and encoding the virtual bytecode as a method;
Including a method. On the computer,
A bytecode class file of the first language having a data structure that encodes the bytecode of the second language on the bytecode of the first language and holds a value referenced from the bytecode of the method call The following functions for generating:
An area used by a virtual bytecode instruction that is a bytecode of the second language that has been rewritten into a format executable by the bytecode processing system of the first language is held in a temporary storage unit A function to secure a predetermined place for each byte code instruction of the second language in the data structure;
A function of converting each instruction in the byte code of the second language into the virtual byte code and holding the virtual byte code in the temporary storage means;
A function of generating a bytecode class file of the first language including the data structure held in the temporary storage means and the virtual bytecode;
A program to realize

Images