OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

47
...
i − 1
iload 3 iload 0x04 iadd istore 2
i i + 1 i + 2 i + 3 i + 4
(a) Before Load Despecialization
...
i + 5
...
i − 1
iload 0x03 iload 0x04 iadd istore 2
i i + 1 i + 2 i + 3 i + 4 i + 5
(b) After Load Despecialization
...
i + 6
Figure 4.1: An Example of Load Despecialization
values of two local variables onto the operand stack, adds them together and then
stores them back into a different local variable. Such a bytecode sequence would be
generated when a Java language statement of the form a = b + c is compiled.
Each box in the diagram represents one byte within the code stream. The top
portion of the figure shows the bytes that make up the code stream before the specialized
load bytecode has been replaced with its equivalent general purpose form. The
lower half of the diagram shows the same block of code after it has been despecialized.
Notice that despecialization increased the number of bytes used to represent the block
of code because it is now necessary to explicitly specify the index from which each
local variable is loaded using an operand.
Performing this despecialization provides semantically equivalent functionality.
However, because the position that must be loaded is now specified using an operand
byte, additional work must be performed at runtime each and every time that bytecode
is executed. In addition, the size of the code stream is increased by one byte for
each load bytecode that is despecialized. The impacts that these changes have on application
performance were measured. They are reported in Section 4.2. In addition,
the overall impact despecialization had on class file size was also measured. These
results are described in Section 4.3. Finally, the impact making these substitutions
has on the correctness of Java class files is described in Section 4.4.