OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

265
to emit four files that were subsequently included into the virtual machine during the
compilation process instead of requiring it to patch the existing files.
The virtual machine generation tool outputs four distinct files that enable the
Kaffe virtual machine to support multicodes. The first contains the declaration of an
array that specifies the size of each bytecode including its operands. Two additional
files describe the tasks that must be performed as part of verifying the correctness
of the class files at the basic block and method level. It is important to note that if
Kaffe is extended to fully implement the verification procedure required by the Java
Virtual Machine Specification then it will likely be necessary to generate several more
files to update a full verifier. The final file generated contains the codelets for all of
the bytecodes supported by the interpreter, including the new multicodes.
B.5 Benchmark Performance Testing Scripts
In order to generate the performance results presented in this thesis, it was necessary
to execute many benchmarks using several different versions of the class files that
represent them. It was also necessary to use the corresponding versions of the Java
library. The following sections describes the scripts used for the despecialization and
multicode studies.
B.5.1
Despecialization Scripts
The first despecialization study conducted used a different script for each virtual
machine tested. This script measured the performance of each benchmark using all
of the rule files located in a prescribed subdirectory. It was responsible for applying
the rule file to every class in the benchmark being tested, every class in the Java
library and invoking the virtual machine in such a manner so as to ensure that only
those classes were utilized. These scripts were subsequently generalized so that a
single script could be used to test an arbitrarily large number of virtual machines.
The timing script executed each benchmark several times. By default, 6 iterations
were used. However, this value could be changed by updating the value of a single
constant within the script. The output from the timing script included an indication
of each rule file tested and the actual output generated when each benchmark was
executed. A separate script was used to parse the performance results. It reported
the average performance of each rule file tested for each benchmark after the highest
and lowest run times were discarded in order to minimize the impact of outliers.