JP2003510681A - Optimized bytecode interpreter for virtual machine instructions - Google Patents

Abstract

(57) [Problem] To provide a method of optimizing the execution time of an interpreted program which is very convenient for an embedded system. SOLUTION: The present invention dynamically replaces a simple operation code original sequence with a new sequence of operation codes of a macro in a virtual machine interpreter of a language based on bytecode, thereby dynamically changing the virtual machine. The present invention relates to a method for optimizing an interpreted program, having a means for reconstructing with a macro operation code. The virtual machine interpreter is encoded as an indirect threading interpreter by a conversion table that includes the implementation address of the operation code that translates the bytecode into the implementation address of the operation code. Applications: Embedded systems using any bytecode-based programming language, set-top boxes for interactive video transmission.

Description

Detailed Description of the Invention

[0001]

TECHNICAL FIELD OF THE INVENTION

The present invention relates to optimizing the execution time of interpreted programs. It more particularly relates to a method of optimizing an interpreted program by a virtual machine that dynamically reconfigures itself with new macro opcodes. The present invention is applicable to any bytecode based programming language.

[0002]

[Prior art]

Bytecode-based languages with programmer-visible stacks are popular as intermediate languages for compilers and as machine-independent executable program representations. These provide significant advantages for network computing. ACM SIGP on Programming Language Design and Implementation (PLDI), June 17, 1998 in Montreal (Canada)
I. Piumanta and F. Riccardi's paper "Optimizing Direct Threaded Code with Selective Inline," pp. 291-300, at Proceedings of the LAN 98 Conference, mentioned in the first paragraph on optimizing interpreted programs. Described technology. A virtual machine (VM) is used by a VM interpreter to interpret a program. A VM is a software implementation that represents the architecture of a virtual processor on which an application compiled specifically for this architecture runs. Virtual processor / machine instructions are called bytecodes. The VM interpreter is the part of the VM that represents the bytecode execution mechanism. The bytecode is interpreted by the VM interpreter. The bytecode execution mechanism is currently implemented as an infinite loop with switch case blocks. The techniques described in the cited paper apply directly to the threaded interpreter. The threaded code interpreter executes bytecode in lines. Each bytecode translation contains a reference to the next bytecode. Therefore, the bytecode executed by the translation threaded interpreter does not participate in the infinite loop. Even though threaded interpreters provide execution advantages, they are inconvenient for most embedded systems because they are too slow and require a lot of memory. In the case of a direct threaded code interpreter, VM bytecodes are represented by the addresses of their implementations, as described in the cited paper, so each bytecode is the implementation of the next bytecode. You can jump directly to. When the bytecode is translated, the physical address of the bytecode implementation is
To be instantly accessible, the table is initialized with the address of each bytecode of the application before the translation operation. This table makes it possible to switch from bytecode to another. Direct threaded interpreters are fast, but they are code extensible. Changing the bytecode directly to threaded code increases the code size by about 150%. This is because the operation codes are replaced by the addresses of their implementation code. In general, an address requires 4 bytes, whereas an operation code requires only 1 byte. Therefore, direct threaded interpreters increase memory consumption and are not well suited for embedded systems.

[0003]

[Means for Solving the Problems]

It is an object of the present invention to provide a method for optimizing the execution time of an interpreted program which is very convenient for embedded systems. Such a system
For example, it may be a satellite or cable transmission system incorporated into a digital video receiver (often called a set top box). The invention applies to any product whose operating system is based on programming language bytecodes. The invention makes it possible to save memory and CPU resources and improve the efficiency of the system.

According to the invention, a method for optimizing an interpreted program in a virtual machine interpreter for a bytecode-based language, the virtual machine converting a simple sequence of bytecodes into a new macrobytecode. A method of dynamically reconfiguring itself by substituting by a sequence and wherein the virtual machine interpreter is encoded as a threaded code interpreter that translates the bytecodes into their implementation code, Has been done. The threaded code interpreter of the present invention includes a bytecode implementation address reference so that during bytecode translation, the address of the next bytecode is retrieved so that the next bytecode can be jumped to. It is encoded by the table as an indirect threaded code interpreter.

The invention and additional features that may optionally be used to implement the invention will be apparent with reference to the drawings described below.

[0006]

BEST MODE FOR CARRYING OUT THE INVENTION

The present invention, which illustrates a novel runtime optimization method applicable to any bytecode-based language, is described in more detail below using the Java language as an example.

The approach normally used by Just-In-Time (JIT) compilers throws away the Java Virtual Machine (VM) interpreter altogether, and leaves the application's bytecode with native machine code (hence Just-In -Time display). The process is to understand the semantics of the original application and re-express it in a more convenient native form. This is an efficient way to achieve performance, but it consumes a lot of memory, on the one hand, as languages based on bytecode are more compact than native code, and on the other hand Java Remapping bytecodes to the target machine is not an easy task and consumes a lot of CPU (Central Processing Unit) resources.

The present invention is also based on some sort of dynamic code generation, the purpose of which is not to translate the Java bytecode of an application into native machine code, but rather a Java VM to a specific bytecode of the application. Dynamically adapting to the execution of the sequence. Therefore, the Java bytecodes of the original application are preserved and the VM is dynamically enriched with new bytecodes or opcodes (opcodes) that improve its execution efficiency.

This approach has several advantages: Does not increase the size of the executable code: This application is memory-
Efficiently left in Java byte-coded display. VM execution mechanism is economical: Since there is only one execution mechanism, the VM executing the application does not have to deal with multiple code representations,
It can reduce its size and improve its reliability. Code generation technology is simple: VM optimizer has a very simple structure, application bytecode analysis is a one-pass table-driven procedure that requires very little CPU resources, and this is a new Directly drives the synthesis of simple bytecodes.

These properties make the present invention suitable for embedded applications. The optimization technique of the present invention is based on an investigation of the cost of the interpreter's very basic mechanism for "typical" application categories. The suitability of an application's profile lies in the potential benefits that can be achieved from the various possible optimization techniques. Applications that have goals embedded and may be defined as "typical" applications include, for example, control applications, graphical user interfaces, and the like.

It is assumed that the target application maps well to the basic instructions provided by the basic VM (Object Manipulation). Therefore, they would not benefit significantly from radical transcoding, but rather from general improvements in VM execution mechanisms. Amdhal's law was used to understand how to improve the efficiency of VMs. In the version by Hennessy and Patterson, Amdhal's law is expressed as: "The performance improvement that results from using one faster execution mode is the time it takes to use that faster mode. Limited by a proportion ", or more commonly:
"Make common cases faster."

The efficiency of the interpreter depends on the mechanism used to dispatch the selected representation and bytecode to the executable code. The first approach to reduce implementation cost was to reduce the cost of instruction dispatching, since a significant part of the interpreter is its instruction dispatching mechanism. A typical interpreter (called a pure bytecode interpreter) is implemented like a processor simulation: large switch statements are in infinite loops and dispatch instructions to their implementation. Therefore, the inner loop of the pure bytecode interpreter is very simple: fetch the next bytecode and dispatch it to the implementation using the switch statement. The interpreter is an infinite loop that contains switch statements that dispatch sequential bytecodes, and passes control to the next bytecode by activating the switch to return control to the beginning of the infinite loop. The following set of instructions shows a typical bytecode interpreter implementation. Loop (Op = * pc ++; Switch (op) {Case op_1: // op_1's implementation break; case op_2: // op_2's implementation break; case op_3: // op_3's implementation break; ...}

Assuming the compiler optimizes the jump chain from the break to its beginning with an implicit jump at the end of the loop, the overhead associated with this approach is: increment the instruction pointer pc, Fetch the next bytecode from memory, check the redundancy range to the argument to switch, fetch the address of the destination case label from the table, jump to that address, and at the end of each bytecode: next byte Return to the beginning of the loop to fetch the code.

In this case, ignoring all other sources of inefficiency, such as the actual implementation of the switch statement, the cost of instruction dispatching consists of: 2 memory accesses: A memory access to retrieve the value of the next instruction, and a memory access to retrieve the address of the instruction's implementation, and two branches: a branch that jumps to the bytecode implementation and another branch that returns to the beginning of the loop. Jump belongs to the most expensive instruction in current architecture.

A pure bytecode interpreter is easy to write and understand. They are also more portable but slower. Therefore, they are not convenient for embedded systems. When most bytecodes perform simple operations, as in the example above, most of the execution time is spent executing dispatch. In fact, in order to recognize the actual cost of the mechanism, it should be compared to the execution cost of a single bytecode. Java
Bytecodes have a very low level of semantics, so their implementation is often simple. Therefore, the most commonly executed bytecodes are actually less expensive than the dispatching mechanism itself.

The first improvement in efficiency of the present invention is the adoption of indirect threaded code as shown by the following set of instructions: Op_1_lbl: // op_1's implementation goto opcode_table (* pc ++); Op_2_lbl: // op_2's implementation goto opcode_table (* pc ++); Op_3_lbl: // op_3's implementation goto opcode_table (* pc ++); where Op_1_lbl, Op_2_lbl and Op_3_lbl represent three different opcodes interpreted by the VM interpreter.

According to this implementation, called indirect threaded code,
The VM is encoded as an indirect threaded code interpreter. During bytecode translation, the address of the next bytecode is parsed. The lookup table, designated opcode_table, contains bytecode implementation addresses. This reference table is accessed by the index of the pointer (* pc ++). For each bytecode translation, the address of the next bytecode is fetched to jump to the next bytecode. In this way, each bytecode implementation jumps directly to the next bytecode implementation, unnecessarily inefficient (range checking) in the implementation of one branch, outer loop, and switch statement. And default case handling) were omitted.

According to a preferred embodiment of the present invention, the translation is carried out by utilizing the unused bytecodes of the bytecode-based language VM specification.

The block diagram of FIG. 1 summarizes the main steps of the inventive method for translating bytecodes (eg bytecode bipush) into native instructions by an indirect threaded code interpreter: step K0 = BIPUSH; Start a method of translating the bytecode bipush consisting of putting 1/2 words on the stack, which is the bipush parameter (par), step K1 = PAR; retrieve the bipush parameter (par) step K2 = PUT; bipush on the stack Put Parameter K3 = GOTO; Go to the next bytecode (goto opcode_table (* pc)) by examining the lookup table opcode_table that contains the address of the implementation of the next bytecode.

While the adoption of threaded code can double the efficiency of the VM itself, it can also provide other interesting optimization opportunities, as can be seen from the description below. According to a statistical analysis of Java bytecodes, on average there is a branch every 5-6 instructions. In any current CPU, branches are inherently expensive instructions because they can cause pipeline stalls and / or trigger external bus activity. Also, for loop unrolling or method call in-lining, there is not much that can really be done about it. The control statements will still be there, even if the code is recompiled to uniqueness.

A recent study on CPU usage for object-oriented applications on high-end workstations showed that the CPU recovered from pipeline stalls due to mispredicted branch statements, and the main memory (cache was 70% of that clock cycle to wait for data and instructions (if none). In addition, CPUs available in embedded systems typically have very small caches, no hardware assistance for dynamic branch prediction, and low and / or narrow memory interfaces without L2 caches. These additional constraints will further reduce CPU utilization and efficiency.

[0022]   Java bytecode can be divided into two categories:   Simple opcodes (load, store, arithmetic and control statements) and   Complex operation codes (memory management, synchronization, etc.).

Simple bytecode is typically cheaper than the dispatching mechanism. Complex bytecodes, on the other hand, are much more expensive, as dispatching costs make up the least part of the total cost of bytecode execution costs.
Simple bytecodes are executed much more frequently (in order of magnitude) than complex bytecodes. This means that the classic Java interpreter spends most of its time doing bytecode dispatching rather than doing useful things. Therefore, it is assumed that reducing dispatching costs for simpler bytecodes than for complex bytecodes is definitely more effective.

Translating bytecodes into indirect threaded code gives the executable code the opportunity to make arbitrary conversions. With such a conversion, a common sequence of bytecodes is detected and they are translated into a single threaded "macrocode". This macro code does work on the entire sequence of original bytecodes. Therefore, according to a preferred embodiment of the invention, it is proposed to replace a sequence of simple bytecodes by some equivalent "macrocode". For example, as disclosed in the cited paper, the bytecode "push literal, push variable, add, store variable" becomes a single "add-literal-to-variable" macro code in indirect threaded code. Can be translated. Such optimizations are effective because they avoid the multiple dispatch overhead that is implied by the original bytecode but is omitted within the macro code. A single macrocode translated from a series of N original bytecodes avoids N-1 bytecode dispatches at run time. More details on how to build macro code can be found in the cited paper. Such macro code would have to meet the following criteria:

Since it does not make sense to reduce the dispatching cost of complex bytecodes, macros must be made up of simple bytecode sequences.

The macro must not contain instructions that are possible branch targets. Otherwise,
The VM execution mechanism will have to be changed significantly. The macro itself can be the branch target.

Since the cost of a native branch is equivalent to the cost of a dispatch operation, the macro must end with a control statement or method call.

For ease of implementation, the maximum macro length should be about 15 byte code. The "natural" average macro length is a 4-5 byte code. From these criteria, constructing such a macro sequence with very little CPU time is very simple. A simple scan of the method's bytecode is actually sufficient, and most parsing can be based on table-driven and single bytecode.

According to a particular alternative of the preferred embodiment, which takes into account that very few unused bytecodes (30-40 on average), for new bytecodes representing new macroinstructions, , 2-byte display can be used. The operands of the original sequence are grouped immediately after the new sequence. This makes them easily accessible by incrementing the program counter of the virtual machine.

Once the process has been scanned, the macro can be constructed by simply cutting and pasting together the binary code generated by the compiler for the threaded code interpreter. Macros can be thought of as normal bytecode by the threading dispatcher.

FIG. 2 outlines a preferred embodiment of the virtual machine of the present invention. The VM is executed to load a program containing bytecode that is interpreted by the VM interpreter. The main steps of this method are as follows: Step K0 = INIT: Initialize the procedure executed by the VM by loading the program containing the bytecode, Step K1 = OPCODE: Retrieve the bytecode to be interpreted , Step K2 = MACRO: Replace a sequence of simple bytecodes with macrobytecodes, Step K3 = TRANS: Interpret macrobytecodes using the indirect threaded interpreter method shown in Figure 1, Step K4 = RES: The result is obtained and the method ends.

According to the statistical analysis performed on the execution trace of the actual Java application,
A typical macro length is 4-5 byte code, and after code conversion, the macro can be executed up to 5 times more often than the rest of the byte code,
found. The rest of the bytecode is that the implementation is too complex to be worth inline and left over by considering branch goal analysis. In this way, the total cost of bytecode dispatching can be reduced by more than a factor of four. The dispatching cost is
If originally accounting for about 50% of the total cost of execution, it can be significantly reduced by using the present invention.

The present invention offers several additional advantages. Processor branch instructions can also be reduced by a factor of five. Since the code executed is linearized, the efficiency of the processor pipeline and memory subsystem can be greatly improved. The actual gain depends on the architecture of the processor for the cost of pipeline stalls and the architecture of the memory subsystem for the cost of cache linefills. "Memory to deal with"
For systems, like most embedded applications, these costs are extremely high and are definitely worth reducing. The rest of the dispatching cost essentially depends on the control statements present in the Java code. In order to fully translate the bytecode into binary code, such as classic dynamic recompilation, branch statements should be introduced into the executable code. This will have roughly the same cost as the rest of the dispatch left.

One of the advantages of macros is that they are general sequences of bytecodes, and one such sequence is found elsewhere or elsewhere in the context of the same process. However, it is extremely high. Testing was done against Java bytecode. It has been found that the useful part of a macro can be reused. Therefore, by considering the reuse factor, the memory usage used by the macrocode implementation can be reduced. A full translation to binary code would use at least twice as much memory and would therefore have negligible efficiency advantages. Assuming that the cost of scheduling could be further reduced by the other two factors, for example, the total increment in observable speed would be very small. Perhaps doubling the memory usage would not be effective.

Another advantage of macros is that they do not have any effect on the normal bytecode dispatching mechanism. There is no need to add any other execution mechanism to what already exists in the VM. There is no need to distinguish between compiled and uncompiled processes, and no reliance on the fate and overhead of native code interfaces.

Object oriented languages like Java are characterized by the presence of very small units of code. Java as they are potentially polymorphic almost always
The process is also very difficult to inline. Thus, even though a fully optimizing compiler can better map process execution semantics to the underlying processor architecture, the preamble and conclusion overhead of a binary translated process often gives any benefit. Will restrain.

Stack catch techniques can be used to improve execution efficiency. This significantly reduces the number of memory accesses and keeps the first three positions of the Java stack inside the processor register file. This technique takes advantage of the fact that the target processor is the stack machine itself. The original bytecode implementation is replaced by the equivalent processor instruction sequence. By using a simple translation table and a simple cost function (number of memory references), a very fast and efficient compilation technique can be achieved. Taking the Java case as an example, the memory input / output cost reduction according to another embodiment of the present invention will be described below.

Java is a stack-based language: Bytecodes use memory to communicate with each other. There is at least one memory access per bytecode execution, which is very expensive. For example, consider the following simple expression: C = a + b; For a stack-based language, this translates to: Push a --1 read 1 write Push b --1 read 1 write Add --2 read 1 write Store c --1 read 1 write This represents 9 memory access operations. A CPU with a minimum internal state can do the same with only three memory accesses. Considering the fact that for current processor architectures memory references belong to the most expensive operations, this is an ideal field of optimization. With little additional coding effort, Java bytecode versions can be made to exchange data by machine registers instead of by external memory.
Then, starting with these specialized bytecodes called strands, we reduce the number of memory accesses within the macro by a factor of more than two,
Macros can be generated.

The implementation of "macroizer" and bytecode "standifier" is
Does not require too many command lines. A partial rewrite of the interpreter loop is C
It can be guessed at, for example, a few thousand lines of code. For an indirect threaded code dispatcher implementation, only a few lines of assembly are needed, and a few hundred lines are used for the "standifier".

Execution time tests and measurements were performed that did not take into account the time spent on bytecode parsing and the generation of new macrobytecode. Nevertheless, the execution time was measured using the native code profiler. When running a large application such as a web browser, "macroization"
The total time spent for ")" remains limited to a small fraction of the total execution time.

A specific example of the receiver of the present invention is shown in FIG. It is a set top box receiver 20 for interactive television transmission. This is a cable transmission channel
23 to receive the coded signal from the video transmitter 24 and to decode the received signal to retrieve the transmitted data displayed on the video display 25 (e.g. MPEG 2 (Moving Pictures Experts group, ISO / It has a decoder (compatible with IEC 13818-2) recommendations. The function of the set-top box is Ja in the form of bytecode.
It can be efficiently implemented by software using a system that runs an interpreted language such as va. This system comprises a main processor CPU and a memory ME, which as described in FIG. 1 or 2, stores a code portion of software representing instructions for the main processor CPU to carry out the method of the invention.
Have M and.

According to another embodiment of the invention, the set top box 20 is capable of receiving Java applications that include bytecode as part of the received signal. In this case, the set top box has a loader that loads a program based on bytecode received from a remote sender.

[Brief description of drawings]

1 is a block diagram illustrating the functionality of the method of the present invention.

FIG. 2 is a block diagram illustrating the functionality of the method according to the preferred embodiment of the present invention.

FIG. 3 is a schematic diagram showing a specific example of the receiver of the present invention.

[Explanation of symbols]

1 Semiconductor substrate 3 surface 4 sources 5 drain 6 floating gate 7 control gate 8 floating gate dielectric 9 Intergate dielectric 10 Select gate 11 Gate dielectric 12 additional doped regions 13 Substantially flat surface area 14 Side wall 15 Real part 16 Side wall spacer 18 metal silicide 19 Dielectric layer 20 contact holes T1 floating gate transistor T2 selection transistor WLi word line SLi selection line BLj bit line

[Procedure amendment]

[Submission date] June 4, 2001 (2001.6.4)

[Procedure Amendment 1]

[Document name to be amended] Statement

[Name of item to be corrected] Brief description of the drawing

[Correction method] Change

[Contents of correction]

[Brief description of drawings]

1 is a block diagram illustrating the functionality of the method of the present invention.

FIG. 2 is a block diagram illustrating the functionality of the method according to the preferred embodiment of the present invention.

FIG. 3 is a schematic diagram showing a specific example of the receiver of the present invention.

[Explanation of symbols] 20 set-top box receiver 23 cable transmission channel 24 video transmitter 25 video display

─────────────────────────────────────────────────── ─── Continued front page    F-term (reference) 5B033 AA01 BB03                 5B081 CC24 DD01

Claims (8)

[Claims] 1. A method for optimizing an interpreted program in a virtual machine interpreter for a bytecode-based language, the virtual machine replacing a simple sequence of bytecodes with a new sequence of macrobytecodes. By dynamically reconfiguring itself and the virtual machine interpreter being encoded as a threaded code interpreter that translates the bytecodes into their implementation code, During translation, a reference is made to the address of the implementation of the bytecode so that the address of the implementation of the next bytecode is retrieved so that the next bytecode can be jumped to. Contains contains reference table Method. 2. The method according to claim 1, wherein the bytecodes of the original sequence are grouped after the new sequence of operation codes of the macro. 3. The virtual machine interpreter has a predetermined set of bytecodes, some of which are unused, and the new sequence of macro operation codes comprises:
Claim 1 or 2 implemented by the unused bytecode
The method described in. 4. The method of claim 3, wherein the unused bytecodes are encoded with a representation of at least 2 bytes. 5. A method for optimizing an interpreted program in a virtual machine for a bytecode-based language, the method comprising the steps of: initializing by loading a program containing said bytecode; Replacing a sequence of bytecodes with macrocodes, interpreting the macrobytecodes using an indirect threaded interpreter that translates the bytecodes into their implementation code, the current byte During the interpretation of the code, the implementation of the bytecode such that the address of the implementation of the next bytecode is retrieved so that it is possible to jump to the next bytecode. Reference to the above address Method having a reference table containing. 6. A memory-loaded computer program product having a set of instructions for causing a processor to perform the method of any of claims 1-5. 7. A processor (CPU) and a memory (MEM) for storing software code portions representing instructions for causing the processor to carry out the method according to claim 1.
And a receiver for receiving the transmitted signal. 8. A method making it possible to download to a receiver according to claim 7 a computer program having instructions for performing the method according to any one of claims 1-5.