OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

259
the level of entropy within the code stream. The implementation of these rules was
considered so that future experiments might be conducted that considered the impact
the order or distribution of the opcodes had on application performance.
The bsub application was developed in C++. Object oriented design principles
were used in order to represent the data that would be handled by the application.
One class was developed which represented a Java class file. Additional class were
created which represented the major structures within it. Examples of these structures
include the constant pool, fields, methods, attributes, bytecodes and exceptions.
A separate class was also developed to represent a rule.
Addition helper functions were also developed. Some of these aided in the task of
parsing the rules in the rule file. Others aided with reading and writing Java class files
by providing an easy mechanism to read or write an element of a specific primitive
data type. Using helper functions to read and write the multi-byte values within the
Java class files made it easy to port bsub from a little endian architecture such as
a Pentium III to a big endian architecture such as SPARC. The only changes made
during the process were in these helper functions.
The input to bsub consisted of the name of a class to process and the name of a
rule file. Each of these values was provided as a command line argument for maximum
flexibility. The first task performed by bsub was to parse the class file and rule file
to verify that the input to the application was syntactically correct.
If each of the input files was loaded successfully then the processing operations
began. Each rule was applied to every method within the class in sequence, in the
same order that they appeared in the rule file. As a result, later rules in the file could
rely on earlier rules executing first. This also made it important that despecializations
were performed in the correct order. For example, because despecializing ifeq
introduces two bytecodes, an iconst 0 and a if icmpeq, it is important to ensure
that iconst 0 is despecialized after ifeq. Otherwise, it is possible that occurrences
of iconst 0 will reside in the output file after despecialization has been performed.
Once every rule was applied to the code attribute for every method, a new version of
the class file was written to disk, replacing the original file.
It has already been observed that performing a despecialization or multicode substitution
is not as simple as replacing all occurrences of a bytecode (for despecialization)
or bytecode sequence (for a multicode substitution) with another bytecode.
These transformations change the total size of the code stream and the distance that
some branches span. Consequently, care was taken to ensure that branches and ex-