OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

49
purpose bytecodes. The notation, , is used to represent an arbitrary small integer,
allowing all four of the specialized bytecodes to be represented using a single
symbol. While not used in Table 4.2, the symbol will be used to represent
any of the primitive types supported by the Java Virtual Machine. As a result, the
symbol store is used to represent an arbitrary specialized store bytecode.
Similarly, the symbol load will be used to denote an arbitrary specialized
load bytecode.
4.1.3 Integer Constant Despecializations
The Java Virtual Machine Specification includes 7 bytecodes used for placing small
integer constants onto the operand stack. These cover the values -1, 0 and 1 through
5. They are generated using the iconst series of bytecodes.
Other facilities are available for placing integer constants onto the stack. These
include the bipush bytecode which is capable of generating any integer constant in
the range -128 to 127 and the sipush bytecode which can be used to generate any
integer constant from -32768 to 32767. While bipush is not normally used to generate
constants from -1 to 5, nothing in the Java Virtual Machine Specification precludes it
from being used for this purpose. Similarly, sipush is not normally used to generate
constants from -128 to 127. However, the Java Virtual Machine Specification does
not specifically restrict it from being used for this purpose.
An additional option is to make use of the appropriate ldc or ldc w bytecode
to load the required value from the constant pool, rather than using bipush or
sipush, which encodes the constant using only operands within the code stream
for the method. Employing this solution results in an additional value being stored
in the constant pool which is loaded through an offset specified as an operand to ldc
or ldc w. While integer constants from -32768 to 32767 do not normally reside in the
constant pool, the Java Virtual Machine Specification does not forbid this.
In this work, integer constants are despecialized by replacing them with appropriate
bipush bytecodes. This choice was made because it is guaranteed to have
the least impact on overall class file size. Analyzing the behaviour of each of the
options also suggests that this selection should have the least impact on application
runtime. If sipush was used instead, it would be necessary to decode two operand
bytes rather than one, resulting in both slower application runtime and larger class
file sizes. Making use of ldc or ldc w would require one or two operand bytes to be
decoded. Following that, a value would need to be copied from the constant pool to