JP2005284729A - Virtual machine compiling byte code into native code - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To make method call more effective in a Java (R) virtual machine for compiling a byte code into a native code to execute it. <P>SOLUTION: A method which is not JIT compiled is executed by an interpreter 1. A method satisfying specified conditions is compiled into a native code 4 by a JIT compiler 2. The JIT compiler 2 decides whether or not the method to be JIT compiled can be executed without creating a frame. As to such a method, a native code to be executed without creating a frame is generated; otherwise, a native code to be executed by creating a frame is generated. Also, all the methods to be JIT compiled may be compiled into native codes which create frames when the necessity arises. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a virtual machine that compiles byte code into native code, and more particularly to a Java (registered trademark) virtual machine that compiles and executes byte code in the Java (registered trademark) programming language. . Java (registered trademark) is a registered trademark of Sun Microsystems, Inc. and is also referred to as Java hereinafter.

In recent years, Java systems are increasingly used in embedded systems such as home appliances and in-vehicle devices. Since the Java program is an interpreter type that executes Java bytecode in a Java virtual machine, the execution efficiency is poor as it is.
Therefore, as one method for speeding up the Java program, there is a method called Just in Time (JIT) compilation in which byte code is compiled into JITed code (in the present invention, called native code) and executed. It is faster than bytecode execution by 1) improving the execution efficiency of the code itself and (2) increasing the efficiency of method calls.
However, in the above-described embedded system or the like, the amount of memory is limited, and there is a situation where the memory becomes insufficient during the operation of the JIT compiler.
Therefore, a method is known in which a part or all of the existing JITed code that can be discarded is discarded, and an area occupied by them is released to obtain a new free memory. For example, Patent Document 1 proposes a method of obtaining free memory by detecting only JITed frames on a thread stack, discovering active methods, and discarding JITed codes of inactive methods. The entire operation to be discarded is called JIT code garbage collection (GC).

Here, the efficiency of the method call will be described. The Java virtual machine has an interpreter stack for each thread. When a method is called, a new frame is pushed onto the interpreter stack, and when returning from a method, a frame is popped.
On the other hand, when a JIT method calls a JIT method, a frame is created on the native stack, similar to a subroutine call of a native code. Calls using the native stack are less expensive than calls using the interpreter stack, which speeds up the program.
However, in a system in which JIT methods call using the native stack, stack scanning during garbage collection (GC) and exception handling when an exception occurs must be performed in the native stack as well as the interpreter stack. I must.
The native stack has a completely different structure from the interpreter stack, the structure depends on the CPU architecture, and (2) a stack of general subroutine frames as well as JIT method frames, etc. There is a problem that is complicated.

In calls using the native stack, if there is a deep call or recursive call in the Java program, the native stack will be greatly expanded. Especially in class initialization, the superclass initialization routine is recursively started, and the native stack is likely to expand. In non-embedded systems, there are few memory restrictions, and since hardware that controls memory access is generally implemented and native stack overflow checking can be performed in hardware, native stack expansion is not a problem. . However, in the above-mentioned embedded system, there are many cases where there is little memory and hardware for controlling memory access is often not implemented.
As described above, in an embedded system, there is a method of using an interpreter stack for method calling of JIT code. This method has the disadvantage that method call efficiency cannot be expected very much, but (1) stack scanning and exception handling can be shared with methods that are not JIT. (2) Although the interpreter stack expands with method calls. The native stack has the advantage of not expanding.
However, there is still a need to make method calls more efficient by suppressing the creation of frames on the interpreter stack as much as possible even in embedded systems.
JP 2000-35890 A

In the prior art, using a native stack for JIT method calls complicates stack scanning and the problem that the native stack expands. On the other hand, using an interpreter stack for method calls speeds up method calls. I can not expect.
SUMMARY OF THE INVENTION An object of the present invention is to solve the above problems and to make method calls more efficient in a Java virtual machine applied to an embedded system or the like that compiles byte code into native code and executes it.
More specifically, an object of the present invention is to provide a JIT compiler that determines whether methods can be executed without creating a frame, and generates native code that can be executed without those methods.
It is another object of the present invention to provide a JIT compiler that generates a native code that creates a frame when a method that is necessary to execute a method is required when the method is executed.
It is another object of the present invention to provide a JIT compiler that determines a method that always requires a frame at the time of execution and generates a native code that does not check for the presence of a frame at the time of execution.
It is another object of the present invention to provide a JIT compiler that calculates the type of the contents of an operand stack at the time of compilation and generates native code having code for caching and decacheing the contents of the operand stack.

(1) In the first feature of the present invention, it is determined whether or not a method to be JIT-compiled can be executed without creating a frame, and the native code is executed without creating a frame for such a method. (Such a method is called a frameless method), and for other methods, generate native code that creates and executes a frame.
Whether the frameless execution can be performed is determined by determining that the method does not call the method further, GC does not occur during the method execution, and the method has no exception handler.
In the frameless method, the arguments are in the interpreter stack, and local variables and operand stacks other than the arguments are in the native stack. Non-frameless methods, like bytecode execution, have both local variables and operand stacks in the interpreter stack.
Whether it is frameless or not is made clear by a flag attached to the native code. When the native code is called, it looks at the flag and creates a frame if it is non-frameless native code, otherwise it starts executing the native code without creating a frame. In the conventional method, a frame is created at the time of every method call. However, in the first feature of the present invention, a method that can be executed without a frame is executed without creating a frame, so that the execution efficiency is improved.
(2) In the second aspect of the invention, all methods that are JITed are compiled into native code that creates a frame when needed.
The native code has local variables in the interpreter stack and operand stacks in the native stack.
When a method call, object allocation, stack scan, or exception occurs during native code execution, the native code creates a frame on the interpreter stack. The contents of the operand stack in the native stack are decached in the interpreter stack. When the method call, object allocation, and stack scan are completed and execution of native code is resumed, the contents of the operand stack in the interpreter stack are cached in the native stack.
According to the second feature of the present invention, a frame is not created in the interpreter stack unless a method call, object allocation, stack scan, or exception occurs during execution of native code, so that execution efficiency is improved.
(3) In the third feature of the present invention, in addition to the second feature of the present invention, the method for JIT compilation is a synchronous method, or there is a method call instruction or an object allocation instruction before the first branch. If so, create a frame immediately after the start of native code execution.
In a method that always requires a frame, the processing to be performed can be omitted if the presence / absence of the frame is not checked during execution of the native code. Therefore, according to the third feature of the present invention, the execution efficiency is improved.
(4) In the fourth feature of the present invention, in addition to the second feature of the present invention, the type of the contents of the operand stack is calculated at compile time, and the operand stack contents cache from the interpreter stack and the operands to the interpreter stack are calculated. Native code has code to decache stack contents.
Since the dedicated code is faster than the general purpose routine, according to the fourth aspect of the present invention, the execution efficiency is improved.

According to the present invention, the following effects can be obtained.
(1) In a JIT compiler that generates native code that uses an interpreter stack, for a method that does not perform a process that requires a frame at the time of execution, a native code that is executed without a frame is generated. Generation can be suppressed.
(2) For a method that does not know whether a frame is necessary at the time of compilation, generation of an unnecessary frame can be suppressed by creating a frame only when a frame is necessary during execution of native code.
(3) For a method that always requires a frame at the time of execution, it is possible to omit checking whether a frame has been created during native code execution by creating a frame immediately after the start of execution of native code. .
(4) At compile time, the operand stack content type is calculated, and the operand stack content is cached from the interpreter stack and the code that decaches the operand stack content to the interpreter stack is generated. It is possible to generate code that performs cache and decache.

(1) First Embodiment FIG. 1 shows the configuration of the entire system of the present invention.
The computer 11 has hardware 12 and an OS 13 and includes a Java virtual machine 10 on 0S13.
The Java virtual machine 10 has an interpreter 1 and a JIT compiler 2. The bytecode 3 of the method is loaded from a file or network. A method that has not yet been JITed is executed by the interpreter 1. When a method is executed by the interpreter 1, a frame is loaded on the interpreter stack 5. A method that satisfies a predetermined condition is compiled into native code 4 by the JIT compiler 2. When the native code 4 is executed, a frame is loaded on the interpreter stack 5 depending on conditions.
FIG. 2 shows a functional configuration of the JIT compiler 2 in the present embodiment. JIT compiler 2 generates determination unit 2a for determining that a method can be executed without a frame, native code generation unit 2b for generating native code that can be executed without a frame, and generation of native code that can be executed with a frame A native code generating means 2c.

FIG. 3 shows a process when a routine for JITing a method by an interpreter is called. When a method is called, if the method has not been JITed, the number of times the method has been called is counted up. If there is a method that has been called more than the specified number of times, JIT is attempted.
That is, as shown in FIG. 3, when the method call is started, it is checked whether the method has been JITed (step S1). If the method is JIT, go to step S6 to execute the native code. If JIT is not performed, the number of times the method is called is incremented in step S2.
Then, it is checked whether it has been called more than the specified number of times (step S3). If it has not been called more than the specified number of times, the bytecode is executed (step S5). If the method has been called more than the specified number of times, the method is JIT compiled (step S4) and the native code is executed (step S6).

FIG. 4 shows processing in this embodiment when a method is JITed.
First, JIT is performed only for the Java method. That is, it is checked whether the method is a Java method (step S1). If it is not a Java method, the process is terminated.
In the case of a Java method, it is determined whether this method can be executed without a frame. This determination is performed by determining whether or not this method satisfies the conditions that no method is called, GC does not occur during the method execution, and the method has no exception handler (see FIG. 4). Steps S2 to S4).
For a method that satisfies the above conditions, a native code that is executed without creating a frame is generated (step S5), and for a method that is not, a native code that is generated and executed is generated (step S6). Then, a flag indicating the presence / absence of a frame is set (step S7).

Here, the determination that the method does not call another method is performed by not including a method call instruction in the byte code of the method.
Further, the determination that GC does not occur during the execution of the method is made by determining that the method bytecode does not include an object allocation instruction, the method is not synchronous, and does not include a synchronous instruction. This is determined by not including instructions that need to be checkpointed. Here, the instructions that need to have a GC checkpoint are a backward branch instruction and a subroutine call instruction (jsr).
Strictly speaking, if the frameless method does not cache the object reference in the native stack or the like, there is no problem even if GC occurs during execution of the frameless method. For example, GC may occur if the contents of the operand stack are not cached in the native stack at the start of method execution. Further, if the type of the contents of the operand stack is checked at the time of JIT compilation of the method so as not to include an object reference, it can be a frameless method even if there is a backward branch instruction.
The JIT method has a flag indicating whether it is frameless or not, and sets a flag indicating the presence or absence of a frame as described above.

In Java method invocation, the calling method pushes the frame onto the interpreter stack, and then the execution of the called method begins.
FIG. 5 shows method call processing according to the first embodiment of the present invention.
First, referring to a flag indicating the presence / absence of a frame (see step S7 in FIG. 4), it is determined whether the native code to be called is frameless (steps S1 and S2). If it is a frameless method, it starts executing native code without creating a frame. Otherwise, after pushing the frame (step S3), execution of the native code is started.
On the other hand, the called method performs frame pop. That is, when compiling a bytecode return instruction, a non-frameless method puts the process of performing a process of popping a frame into the code, but the frameless method does not.

The contents of the interpreter stack and native stack when the frameless method is executed will be described with reference to FIG. 6A shows the contents of the interpreter stack, and FIG. 6B shows the contents of the native stack.
In this frameless method example, arguments (arguments) are in the interpreter stack, and local variables and operand stacks other than arguments are in the native stack. However, a RISC architecture CPU may have all the contents of the operand stack in a register.
Here, a method composed of byte code strings of “alload — 0”, “getfield” and “irreturn” is taken as an example. Note that allo_0, getfield, and ireturn are byte code expressions, but those compiled into native code are executed.
In this example, there is one argument, zero non-argument local variables, and therefore one local variable.

In the initial state, arguments are stacked on the interpreter stack, and the native stack is empty (FIG. 6 (i)).
allow_0 is converted into code that pushes the zeroth local variable onto the native stack. When this JIT code is executed, the object reference (A in FIG. 6) of the interpreter stack is pushed onto the native stack (FIG. 6 (ii)).
getfield gets the field value of the object reference at the top of the native stack, is converted to code that pops the object reference (A in FIG. 6) and pushes the field value (B in the figure).
When this JIT code is executed, an object reference (A in FIG. 6) is popped on the interpreter stack and a field value (B in the figure) is pushed on the native stack as shown in FIG. 6 (iii)).
irturn is converted to a code that writes the value at the top of the native stack to the top of the caller frame's operand stack. In the frameless method, the top of the operand stack of the caller frame always coincides with the 0th local variable of the callee method. In this case, the code is converted to the code written to the 0th local variable.
When this JIT code is executed, the value at the top of the native stack (B in the figure) is written into the interpreter stack (FIG. 6 (iv)).
Here, the top of the caller's frame stack remains unchanged when the frameless method is called, and is decreased by the argument size and increased by the return value size when returning from the frameless method.

Next, second to fourth embodiments of the present invention will be described.
In the second to fourth embodiments described below, all methods to be JIT are compiled into native code that creates a frame when needed.
Further, in the third embodiment, in the above, it is checked whether the method is a method in which a frame is always created during execution of native code, and in that case, the code for creating a frame is inserted at the beginning of the native code. It is.
Furthermore, in the fourth embodiment, in the above, the type of contents of the operand stack is calculated for each instruction at the time of compilation, and the code for performing cache and decache of the operand stack is generated based on the contents of the operand stack. It is a thing.
FIG. 7 shows a functional configuration of the JIT compiler 2 in the second to fourth embodiments of the present invention. The JIT compiler 2 of the second to fourth embodiments includes a native code generation unit 2d that generates a native code having a function of creating a frame when necessary, and whether a method always requires a frame at the time of execution. Discriminating means 2e, means 2f for generating a native code for creating a frame in the case of a method requiring a frame, calculation means 2g for calculating a stack map, and native code for caching and decacheing an operand stack Means for generating 2h.

(2) Second Embodiment FIG. 8 shows processing when JITing a method according to the second embodiment of the present invention.
In this embodiment, there is no distinction between “method for creating a frame” and “method for not creating a frame” as in the first embodiment, and all the methods to be JIT are the native code shown in FIG. The code generation means 2d compiles it into native code that creates a frame when needed.
That is, as shown in FIG. 8, it is checked whether the method is a Java method (step S1). If it is not a Java method, the process is terminated. If it is a Java method, native code that creates a frame when necessary. Is generated (step S2). This generated native code determines whether a frame is created at runtime when a method call, object allocation, stack scan, or exception occurs during native code execution, and if it has not been created, it is added to the interpreter stack. Make a frame.
The native code according to the second embodiment also has an operand stack in the native stack, but has local variables in the interpreter stack, whether they are arguments or not. However, a RISC architecture CPU may have all the contents of the operand stack in a register.

FIG. 9 shows the state of the interpreter stack during native code execution. FIG. 9A shows the contents of the interpreter stack before execution, and FIG. 9B shows a state in which a frame is created.
At the start of native code execution, only the frame of the caller method is on the stack, as shown in FIG. For invoked methods, only local variables are placed on the stack.
When a method call, object allocation, stack scan, or exception occurs during execution of native code, the native code creates a frame on the interpreter stack as shown in FIG. Also, the contents of the operand stack in the native stack or register are decached (copied) into the interpreter stack.
Furthermore, when the method call, object allocation, and stack scan are completed and execution of native code is resumed, the contents of the operand stack in the interpreter stack are cached (copied) in the native stack or register.

FIG. 10 illustrates native code that creates a frame when it is needed, using ifeq as a bytecode as an example.
ifeq is an instruction that pops the top value of the operand stack and branches when it is zero. If this branch is a backward branch, it is necessary to enter a GC checkpoint when there is a GC request before the instruction is executed.
Here, the GC checkpoint will be described. Since the interpreter stack is the root of the object reference, it must be scanned during GC. However, for execution efficiency, the contents of the interpreter stack may be cached elsewhere (not consistent). The same applies to interpreter execution.
In order to perform a stack scan, the interpreter stack of all threads must be consistent. Also, when GC becomes necessary, it is necessary to perform GC as quickly as possible.
Therefore, a GC checkpoint in which the interpreter stack is consistent and stack scan is possible must be placed in the loop. Since a backward branch instruction is always used for a loop, a checkpoint is placed at the backward branch instruction (the same applies to jsr).

Next, the processing of FIG. 10 will be described in the order of row numbers. FIG. 10 shows the assembler language of the Intel CPU.
Line 1 is a process for acquiring whether there is a GC request. If there is a GC request, non-zero is returned to the EAX register, otherwise zero is returned.
Lines 2 to 3 are processes for jumping to label2 when there is no GC request.
Line 4 is a process for acquiring a pointer to the frame of the currently executed method. If a frame has already been created, a pointer to the frame is returned in the EAX register, and null if it has not been created.
Lines 5 to 6 are processes for jumping to label 1 when a frame has already been created.
Line 7 is a process for calling a subroutine for creating a frame.
Line 9 is a process for decacheing the contents of the operand stack in the native stack to the interpreter stack.
Line 10 is the process that enters the GC checkpoint.
Line 11 is a process for caching the contents of the operand stack in the interpreter stack in the native stack.
Lines 13 to 15 are ifeq processing. That is, one word is popped from the operand stack, and if it is zero, jump to address1. Here, address 1 is the address of the native code corresponding to the offset of the byte code.
In the native code according to the second embodiment, the presence or absence of a frame is checked when returning, and if a frame is created, it is popped, and if it is not created, it is returned without being popped.

(3) Third Embodiment In the second embodiment described above, if a method call, object allocation, stack scan, or exception occurs during native code execution, it is checked whether a frame has been created. Is trying to do the process of making.
However, when the method is a synchronous method, or if there is a method call instruction or an object allocation instruction before the first branch, a frame is created during execution of native code.
Therefore, in such a method, creating a frame from the beginning is more efficient than checking for the presence of a frame during native code execution.
In the third embodiment, the determination means 2e of FIG. 7 determines whether the method is a synchronous method at the time of JIT compilation, or whether there is a method call instruction or an object allocation instruction before the first branch. If so, the native code generating means 2f generates a native code for creating a frame and inserts it at the beginning of the native code.
Further, assuming that a frame is already formed during execution of the native code, in the method calling instruction, the object allocation instruction, the stack scan, and the exception native code, the processing to be performed if the existence of the frame is not checked is omitted.

FIG. 11 shows processing when JITing a method according to the third embodiment of the present invention. If the method is a Java method (step S1), if it is not a Java method, the process ends. If it is a Java method, the method is checked to determine if it is a synchronous method (step S1). A native code for generating and executing a frame is generated (step S5). If it is not a synchronous method, it is checked whether there is a method call or object allocation instruction before the first branch (step S3). If so, native code that creates and executes a frame as described above. Is generated (step S5).
Otherwise, a native code that creates and executes a frame when necessary is generated (step S4).

FIG. 12 shows the native code of the ifeq according to this embodiment of the method having a frame at all times.
The native code generated by the present embodiment is a form in which the fifth, sixth, seventh, and eighth lines are omitted from the native code of the second embodiment shown in FIG. If it has been created, the process of jumping to label1 and the process of calling a subroutine for creating a frame are omitted.

(4) Fourth Embodiment When the contents of the operand stack are cached or decached during the execution of the JIT code in the second embodiment, the size of the operand stack (how many values It is known at the time of execution). Also, regarding the arguments and return values when calling a method, the type is known from the method signature. Therefore, cache and decache are possible based on these information.
However, in this case, it is necessary to obtain the number and type of values every time it is executed.
On the other hand, in Java bytecode, the type of the contents of the operand stack at the time of execution of an instruction is determined regardless of the path. That is, the type of contents to be cached and decached at the time of compilation is determined. Therefore, a cache code that matches the contents of the operand stack during execution of a certain bytecode can be put in the native code.
Therefore, at the time of compiling, the type of the contents of the operand stack is obtained by the calculation means 2g for calculating the stack map of FIG. 7, and the cache and decache are generated by the native code code generation means 2h based on the type of the contents of the operand stack. Generate native code to In this way, it is not necessary to acquire the number and type of values each time execution is performed, and execution efficiency is better than cache and decache using a general-purpose routine.
As described above, in the present embodiment, the type of the contents of the operand stack is calculated for each instruction at the time of compilation, and the native code for performing the cache and decache of the operand stack is generated based on the contents of the operand stack.

FIG. 13 shows a process for calculating the type of the contents of the operand stack at the time of compilation according to the fourth embodiment.
In FIG. 13, in load_0, an object reference is stacked on the operand stack. In iload_1, an integer type is stacked.
Invokevirtual java. lang. String. charAt () is a method that takes a String class object and a single integer as arguments and returns a single char type.
Therefore, when this method is executed, the object reference and the integer type are popped, and the integer type is stacked as shown in FIG. (In Java, the char type is 32 bits when stacked on the stack)

In this case, one object reference and one integer type may be decached in the interpreter stack in the decache before invokevirtual.
In addition, in the cache after the invokevirtual, one integer type may be cached in the native stack or register.
It is necessary to acquire a signature of a method to be called (here, java.lang.String.charAt ()) at the time of invoking in the general-purpose routine cache and decache, and perform cache and decache by referring to the signature. That is, in the case of decache processing in a general-purpose routine written in C language or the like, a method signature is obtained from a method block, and signature entries (in this case, one char type and one reference type in total) are obtained. Although it must be decached while analyzing one by one, it is not necessary in the fourth embodiment of the present invention.

It is a block diagram of the whole system of this invention. It is a block diagram which shows the function structure of the JIT compiler in the 1st Embodiment of this invention. It is a figure which shows the process in which the JIT compilation of a method is performed during interpreter execution. It is a figure which shows the process which carries out JIT compilation of the method of frameless and it is not. It is a figure which shows the process which performs the native code | cord | chord of the method of frameless and that which is not so. It is a figure which shows the mode of the interpreter stack and native stack during frameless method execution. It is a block diagram which shows the function structure of the JIT compiler in the 2nd-4th embodiment of this invention. It is a figure which shows the process which JIT compiles the native code made when a frame is needed during execution. It is a figure which shows a mode that a frame is produced during native code execution. It is a figure which shows the example of the native code made when a frame is needed during execution. FIG. 10 is a diagram illustrating processing for generating a code for creating a frame in the case of a method that always creates a frame. It is a figure which shows the example of the native code of the method which always makes a frame during execution. It is a figure which shows the process which calculates the type of the contents of an operand stack during compilation.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Interpreter 2 JIT compiler 3 Byte code 4 Native code 5 Interpreter stack 6 Native code stack 10 Java virtual machine 11 Computer 11
12 Hardware 13 OS

Claims (5)

A virtual machine with means to compile bytecode into native code during program execution,
The means for compiling includes means for determining that a method to be compiled can be executed without a frame;
If it can run without a frame, it can generate native code that can be run without creating a frame,
A virtual machine comprising means for generating native code for creating and executing a frame when it cannot be executed without a frame. A virtual machine with means to compile bytecode into native code during program execution,
The means for compiling is as follows:
When processing that requires a frame occurs during the execution of a compiled method, code that determines whether a frame corresponding to that method has been created on the interpreter stack, and if the frame has not been created, A means of generating code that creates a frame of native code that is running;
The interpreter stack includes means for generating code for decached the contents of the operand stack of the native code being executed, and code for caching the contents of the operand stack of the native code being executed from the interpreter stack. A virtual machine. The means for compiling according to claim 2 includes means for determining that a method to be compiled from now requires a frame, and inserting a code for creating a frame into the native code when a frame is required. A virtual machine characterized by that. The means for compiling according to claim 2 or claim 3 comprises means for calculating the type of contents of the operand stack for each bytecode instruction at compile time;
Code to decache the contents of the operand stack in the interpreter stack;
A virtual machine comprising means for generating code for caching the contents of an operand stack from an interpreter stack. A program for compiling in a virtual machine with a function to compile bytecode into native code during program execution,
The above program
When processing that requires a frame occurs during the execution of a compiled method, code that determines whether a frame corresponding to that method has been created on the interpreter stack, and if the frame has not been created, Processing to generate code that creates a frame of native code that is running;
Causing the interpreter stack to execute a process for generating a code for decaching the contents of the operand stack of the native code being executed and a code for caching the contents of the operand stack of the native code being executed from the interpreter stack. A program characterized by

Images