OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

177
∆ x1 /x 2 /x 3 /.../x n→ and ∆ x1 x 2 x 3 ...x n→ and the cost of the transfers that are removed. Unfortunately
each of these values are also difficult to determine.
Attempts were made to estimate the difference in cost between ∆ x1 /x 2 /x 3 /.../x n→
and ∆ x1 x 2 x 3 ...x n→ by examining the assembly language implementations of each. The
number of Intel assembly language instructions was counted and the difference was
used as an estimate of the change in performance.
did not give good results.
Unfortunately this technique
Because the Pentium III is a complex instruction set
computer, the amount of time required to execute its instructions varies. Furthermore,
simply counting the number of assembly language lines failed to consider many other
interactions within the assembly language such as the cost of branches within the
codelet and pipeline stalls associated with adjacent accesses to the same data. As a
result, this technique was abandoned in favour of a strategy that takes these factors
into consideration.
While it is difficult to perform an analysis to determine the change in performance
associated with a multicode substitution, the difference in performance can
be measured relatively easily. A baseline execution time can be established by running
an application in its original, unmodified form. Once the multicode substitution
has been performed, the application is executed a second time.
The difference in
execution time is ε x1 x 2 x 3 ...x n→. Since the number of times the multicode sequence is
executed is known, the value of ∆ x1 x 2 x 3 ...x n→ can also be determined.
Initial attempts used micro-benchmarking in order to determine the ∆ x1 x 2 x 3 ...x n→
for each bytecode sequence being considered. This involved constructing a new Java
class file that contained a main method and a timing method. The main method
invoked a static method which performed the timing. It was not possible to perform
the timing directly in the main method because the Java Language Specification
requires the main method to take a single object reference parameter, making it
impossible to test bytecode sequences that made use of one of the load 0 or
store 0 bytecodes other than aload 0 or astore 0. The algorithm followed by
the timing method is shown in Figure 7.23.
Building the timing method was a non-trivial undertaking. There was no guarantee
that the bytecode sequence being tested would be stack neutral. This meant that
it could require certain data values to be present on the stack before it executed and
that it might leave some data values on the stack after it completed. Determining
what these values were was complicated by the fact that there are some Java bytecodes
which work with stack values of variable type. Examples of such bytecodes are
getstatic, putstatic, getfield and putfield. In addition, other bytecodes such