Soot - a Java Bytecode Optimization Framework

Soot - a Java Bytecode Optimization Framework Raja Vallée-Rai Phong Co Etienne Gagnon Laurie Hendren Patrick Lam Vijay Sundaresan Sable Research Group School of Computer Science McGill University Abstract support; applications written in Java are often much slower than their counterparts written in C or C++. This paper presents Soot, a framework for opti- To use these features without having to pay a great mizing Java bytecode. The framework is imple- performance penalty, sophisticated optimizations mented in Java and supports three intermediate rep- and runtime systems are required. Using a Just-In- resentations for representing Java bytecode: Baf, Time compiler[1], or a Way-Ahead-Of-Time Java a streamlined representation of bytecode which is compiler[21] [20], to convert the bytecodes to na- simple to manipulate; Jimple, a typed 3-address in- tive instructions is the most often used method for termediate representation suitable for optimization; improving performance. There are other types of and Grimp, an aggregated version of Jimple suit- optimizations, however, which can have a substan- able for decompilation. We describe the motiva- tial impact on performance: tion for each representation, and the salient points in translating from one representation to another. Optimizing the bytecode directly: Some byte- In order to demonstrate the usefulness of the code instructions are much more expensive framework, we have implemented intraprocedural than others. For example, loading a local vari- and whole program optimizations. To show that able onto the stack is inexpensive; but virtual whole program bytecode optimization can give per- methods calls, interface calls, object alloca- formance improvements, we provide experimen- tions, and catching exceptions are all expen- tal results for 12 large benchmarks, including 8 sive. Traditional C-like optimizations, such SPECjvm98 benchmarks running on JDK 1.2 for as copy propagation, have little effect because GNU/Linux . These results show up to 8% im- they do not target the expensive bytecodes. To provement when the optimized bytecode is run us- perform effective optimizations at this level, ing the interpreter and up to 21% when run using one must consider more advanced optimiza- the JIT compiler. tions such as method inlining, and static virtual method call resolution, which directly re- 1 Introduction duce the use of these expensive bytecodes. Java provides many attractive features such as plat- Annotating the bytecode: Java’s execution form independence, execution safety, garbage col- safety feature guarantees that all potentially il- lection and object orientation. These features facil- legal memory accesses are checked for safety itate application development but are expensive to before execution. In some situations it can be determined at compile-time that particular The authors’ e-mail addresses are: rvalleerai, pco, gagnon, checks are unnecessary. For example, many hendren, plam, vijay @sable.mcgill.ca, respectively. This re- array bound checks can be determined to be search was supported by IBM’s Centre for Advanced Studies (CAS), NSERC and FCAR. Java is a trademark of Sun Mi- completely unnecessary[14]. Unfortunately, crosystems Inc. after having determined the safety of some array accesses, we can not eliminate the bounds .java checks directly from the bytecode, because they are implicit in the array access bytecodes and can not be separated out. But if we can javac communicate the safety of these instructions optimizations to the Java Virtual Machine by some anno- .class tation mechansim, then the Java Virtual Ma- chine could speed up the execution by not performing these redundant checks. Baf optimizations The goal of our work is to develop tools that simplify the task of optimizing Java bytecode, and to demonstrate that significant optimization can be Grimp Jimple achieved using these tools. Thus, we have developed the Soot[24] framework which provides a set of intermediate representations and a set of Java APIs for optimizing Java bytecode directly. The optimizations optimized bytecode can be executed using any stan- dard Java Virtual Machine (JVM) implementation, or it could be used as the input to a bytecode C or Figure 1: The Soot Optimization Framework con- bytecode native-code compiler. sists of three intermediate representations: Baf, Jimple and Grimp. Based on the Soot framework we have implemented both intraprocedural optimizations and whole program optimizations. The framework has 2 Framework Overview also been designed so that we will be able to add support for the annotation of Java bytecode. We The Soot framework has been designed to sim- have applied our tool to a substantial number of plify the process of developing new optimizations large benchmarks, and the best combination of op- for Java bytecode. To do this we have developed timizations implemented so far can yield a speed three intermediate representations: Baf, a stream- up reaching 21%. lined representation of bytecode which is simple to manipulate; Jimple, a typed 3-address interme- In summary, our contributions in this paper are: diate representation suitable for optimization; and (1) three intermediate representations which pro- Grimp, an aggregated version of Jimple suitable for vide a general-purpose framework for bytecode op- decompilation. Section 3 gives more detailed de- timizations, and (2) a comprehensive set of results scriptions of each intermediate representation. obtained by applying intraprocedural and whole Optimizing Java bytecode in Soot consists of program optimizations to a set of real Java appli- transforming Java bytecode subsequently to Baf, cations. Jimple, Grimp, back to Baf, and then to bytecode, The rest of the paper is organized as follows. and while in each representation, performing some Section 2 gives an overview of the framework. Sec- appropriate optimization (see figure 1.) tion 3 describes the three intermediate representations used, in detail. Section 4 describes the steps 3 Intermediate Representations required to transform bytecode from one intermediate representation to another. Section 5 describes Baf, Jimple, and Grimp are three unstructured rep- the current optimizations present in the Soot frame- resentations for Java bytecode. They were devel- work. Section 6 presents and discusses our exper- oped to allow optimizations and analyses to be per- imental results. Section 7 covers the conclusions formed on Java bytecode at the most appropriate and related work. level. Each representation is discussed in more detail below, and figures 2, 3, 4 and 5 provide an ex- that the local variables are given explicit names, ample program in each form. and that there are some identity instructions at the beginning of the method to mark the local variables with pre-defined meanings, such as this. 3.1 Baf Motivation 3.2 Jimple Although the primary goal of the Soot framework Motivation is to avoid having to deal with bytecode as stack code, it is still sometimes necessary to analyze or Optimizing stack code directly is awkward for mul- optimize bytecode in this form. We use it in two tiple reasons, even if the code is in a streamlined ways. First, in order to produce Jimple code, it is form such as Baf. First, the stack implicitly par- necessary to perform abstract interpretation on the ticipates in every computation; there are effectively stack. Second, before producing new bytecode, it two types of variables, the implicit stack variables is convenient to perform some peephole optimiza- and explicit local variables. Second, the expres- tions and stack manipulations to eliminate redun- sions are not explicit, and must be located on the dant load/stores. These analyses and transforma- stack[30]. For example, a simple instruction such tions could be performed on Java bytecode directly, as and can have its operands separated by an ar- but this is tedious for two reasons: encoding issues, bitrary number of stack instructions, and even by and untyped bytecodes. basic block boundaries. Another difficulty is the One of the many encoding issues to deal with is untyped nature of the stack and of the local vari- the constant pool. Bytecode instructions must re- ables in the bytecode, as this confuses some anal- fer to indices in this pool in order to access fields, yses which expect explicitly typed variables. A methods, classes, and constants, and this constant fourth problem is the jsr contained in the byte- pool must be tediously maintained. Baf abstracts code instruction set. The jsr bytecode is difficult away the constant pool, and thus it is easier to ma- to handle because it is essentially a interprocedu- nipulate Baf code. ral feature which is inserted into a traditionally in- Another problem with Java bytecode is the pres- traprocedural context. ence of untyped bytecodes. A large proportion of the bytecodes are fully typed, in the sense that their Description effect on the stack is made explicit by the opcode. For example, the iload instruction indicates that Jimple is a 3-address code representation of byte- an integer is loaded on to the stack. A few instruc- code, which is typed and does not include the 3- tions, however, have been left untyped. Two ex- address code equivalent of a jsr (jsr instructions amples are dup and swap. In order to determine are allowed in the input bytecode, and are elimi- their exact effect one must already know what types nated in the generated Jimple code). It is an ideal are on the stack, and thus typed stack interpretation form for performing optimizations and analyses, must be performed. This step can be avoided by us- both traditional optimizations such as copy prop- ing Baf because each Baf instruction has an explicit agation and more advanced optimizations such as type. virtual method resolution that object-oriented lan- guages such as Java require. Essentially, the stack Description has been eliminated and replaced by additional local variables. Additionally, the typed nature of the Baf is a bytecode representation which is stack bytecode and the untyped nature of the local and based, but without the complications that are stack area variables have been reversed; the op- present in Java bytecode.

Load more