OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

262
The internal data structure used to store the information about each bytecode
executed was a C++ STL map. The keys in the map were Instruction objects.
Each value in the map was an integer which represented the count of the number
of times the instruction executed. An instruction object consisted of an opcode, a
vector of operands and a comment string. Each time a bytecode was executed, a new
instruction object was created to represent it. If the object was not already present
in the map, it was added to it with a count of one. Otherwise, the count associated
with the object in the map was incremented.
An exit handler was installed in order to ensure that the data collected was saved
to a file when the application completed. The file format was text based, using one line
to represent each unique opcode / operand pairing executed. Each line began with an
integer indicating how many times the instruction executed. This was followed by an
ASCII representation of the opcode name and any operands or comments recorded
for that opcode.
Perl scrips were developed to process the output files generated from profiling the
benchmarks with this virtual machine. Those scripts generated lists of the load and
store bytecodes executed by the application sorted by execution frequency. They were
also used in order to evaluate the constants utilized, number of parameters to each
method invoked, and the type information associated with each method parameter,
field and object. Without these scripts it would have been impossible to conduct the
studies presented in Chapter 5 and Chapter 6.
B.2.2
Multicode Block Profiling Virtual Machine
The multicode block profiling virtual machine was also constructed by modifying the
Kaffe virtual machine. It used an approach that was similar to the operand profiling
virtual machine. Individual bytecodes were represented using integers instead of
objects because it was not necessary to store information regarding their operands.
A sequence of bytes representing a multicode block was expressed as a C++ STL
vector of integers because this data structure was flexible and easy to use. The
execution count associated with each bytecode sequence was stored in a C++ STL
map.
In order to identify the starting point for each multicode block, it was necessary
to determine the target of each branch, the start of each exception handler and the
start and end of each exception handler range. This information can be determined
by examining the code attribute and the exception table. A map was used to save this