OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

34
Nisbet. Their work made use of an automatic interpreter generation tool named
vmgen. It has been used to generate interpreters which included super instructions
for both Forth and Java [47]. In their study, three virtual machines were generated.
Each virtual machine considered super instructions of a single length. The super
instructions were identified based on profiling data collected from two applications.
Few additional details are provided about the technique used to identify the bytecode
sequences replaced with super operators except for an indication that they did not
explore building a virtual machine with a set of super operators of variable length.
The super instruction lengths considered were 2, 3 and 4 bytecodes.
Casey et. al. also published a second work involving super operators [33]. In this
study a static analysis of Java class files was employed in order to select bytecode
sequences to be represented by super operators. This choice was made based on the
fact that previous work on Forth showed that this selection strategy was effective [55].
However, it has been shown that the static and dynamic distributions of bytecodes
for Java applications are not correlated in many applications [43].
The notion of Semantically Enriched Code (sEc) was developed by researchers
at Hewlett-Packard Laboratories [116]. The general idea was to identify those basic
blocks that execute with greatest frequency and introduce a mechanism for handling
them with a single instruction. This was accomplished by annotating the class file
with sEc-hook information that indicates the method descriptor, offset and number
of instructions that should be replaced with a new sEc bytecode. A new class loader
was introduced to identify the presence of this annotation and handle the basic block
as a special case. Alternatively, the virtual machine could be modified ahead of time
along with the code attributes of the Java class file, replacing the basic block with a
new opcode. The performance results presented in the sEc study consider only the
static replacement of two basic blocks in a single benchmark.
Each of these areas of previous work shares some commonality with the multicode
work presented in Chapter 7. However, the multicode work is distinct in that it
considers the creation of new opcodes that completely replace the previously existing
sequences. This is distinct from the work conducted by Casey et. al. who replaced
only the first opcode in the sequence, leaving the remaining opcodes in place. Multicodes
are also distinct from Casey et. al.’s work in that sequences of as many as
50 bytecodes are considered for replacement compared to sequences of 4 bytecodes or
less in Casey et. al.’s work.
Multicodes are distinguished from the sEc work by the fact that arbitrary bytecode
sequences are considered. In the sEc implementation, a sequence of bytecodes