OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

152
problem occurs for exceptions as was found for branching – there is no straight forward
way to indicate what portion of a multicode is handled by one exception handler and
what portion is handled by another exception handler. In addition to the difficulties
with expressing the exception handler ranges, allowing a multicode to be split across
multiple exception handlers would have serious implications for any optimizations that
change the order of execution of the statements that implement the functionality of
the multicode. As a consequence, substitutions are not performed on occurrences of
the sequence if any entries in the exception handler list includes a start pc, end pc
or handler pc value that specifies a bytecode other than x 1 .
A class file mutator tool was developed that is capable of modifying Java class
files. This tool is able to perform the despecializations described in previous chapters
as well as multicode substitutions. Its input consists of a Java class file and a rule file
which describes a set of manipulations to apply to the class file. Two rule types are
supported: despecialization rules and multicode substitution rules. A despecialization
rule includes a single opcode name and replaces all occurrences of that opcode with
its equivalent general purpose form. A substitution rule consists of a list of bytecodes
that make up the multicode and a (free) opcode that will be used to represent the
multicode in the code streams. The substitution rule to replace all occurrences of the
bytecode sequence aload 0 getfield is shown below:
substitute aload 0 getfield -> o203
Unfortunately, the bytes saved by replacing the bytecode sequence with a multicode
complicate the substitution process slightly. Because of the change in size, extra
work must be performed for some bytecode operands in order to ensure that they
refer to the correct location in the code stream after the substitution is performed.
Problematic bytecodes include all of the conditional branch bytecodes as well as the
goto and goto w bytecodes. Updates must also be performed in order to ensure that
exceptions cover the same bytecode ranges after despecialization is performed.
Figure 7.6 illustrates the adjustment that must be performed to the operands
of an ifeq bytecode. The top portion of the figure shows the original code stream
before multicode substitution has been performed. The bytecode sequence aload 0
→ getfield has been replaced with a multicode, denoted by mc in the lower portion
of the diagram. Notice that performing this substitution has reduced the value of the
second operand to ifeq by one because the distance spanned by the branch has been
reduced by one byte. The technical implementation details describing how this size
change was handled by the class file mutator tool are presented in Section 11.