a Not yet implemented in current version SPARK: Research Kit Pointer Analysis Parameters Soot Pointer analysis. Objectives

Transcription

1 SPARK: Soot Reseach Kit Ondřej Lhoták Objectives Spak is a modula toolkit fo flow-insensitive may points-to analyses fo Java, which enables expeimentation with: vaious paametes of pointe analyses which affect accuacy and efficiency vaious implementations of pointe analyses vaious client analyses Paametes Spak allows expeimentation with the following paametes that affect the accuacy, efficiency, and size of the esult of a pointe analysis. Subset (Andesen) o unification (Steensgad)? Appopiate level of context sensitivity? a Ae object instances distinguished in field/aay efeences? Ae vaiables in SSA fom, UD-DU webs, o as in oiginal souce? Ae declaed types and casts espected? Is an initial call gaph equied, o is it constucted duing the pointe analysis? Is the initial call gaph built by CHA, RTA, VTA,...? a Not yet implemented in cuent vesion

2 Soot Oveview Bytecode Jimplify Jimple Analyses, Optimizations, and Annotations Optimized Jimple Optimized Bytecode Jimple Call Gaph Timme Call Gaph Side-effect Engine Native Method Escape Simulato Othe Client Analyses Spak is a component of Soot, a famewok fo analyzing, optimizing, annotating, and decompiling Java class files. It suppots a numbe of intemediate epesentations of vaying levels, anging fom stack-based, bytecode-like Baf to stuctued, Java-souce-like Dava. Most analyses and tansfomations in Soot, and the Spak famewok in paticula, opeate on Jimple, a stackless, typed, thee-addess intemediate epesentation. Spak in Soot Call Gaph Side-effect Othe Optimized Infomation Soot Annotated Analyses Jimple Escape Annotation Optimized Annotated Infomation Geneato Bytecode Spak eads the Jimple intemediate epesentation poduced by Soot, and computes may points-to infomation fo all pointe vaiables in the pogam. This infomation allows client analyses to detemine whethe two pointe vaiables may be aliased, as well as the types that may each each vaiable. The esults of these client analyses can be used futhe by Soot, o encoded in class file attibutes fo use by a JIT compile o othe optimize. Engine Jimple Call Gaph Native Method Simulato Assignment Gaph Builde Assignment Gaph Solve Result The pointe analysis engine consists of two main components: The builde builds a simple intemediate epesentation of the flow of pointes in the pogam. analysis paametes detemine how the featues of the pogam ae epesented. A solve poduces the equied may points-to infomation. The solve is mostly independent of the pointe analysis paametes. We can expeiment with vaious solve implementations.

3 Assignment Gaph p new C p q.f p q p.f q The pointe assignment gaph is a flow-insensitive epesentation of the pogam souce. Simple ( p ) o field efeence ( p.f ) nodes (depending on pointe analysis paametes) epesent all locations stoing pointes. Fo a context sensitive analysis, multiple nodes may epesent a single vaiable in diffeent contexts. Edges epesent not just explicit assignments, but also flow though method paametes, etun values, and exceptions. Some o all edges can be made bi-diectional fo a unification-based analysis. Evey node has a declaed type which the solve may use. Example 1 static void foo() { a1: p = new O(); q = p; a2: = new O(); p.f = ; t = ba( q ); p new O static O ba( O s ) { etun s.f; q f This gaph would be made fom the code fagment by a unification-based analysis, epesented by bi-diectional edges. Object instances ae not distinguished, so a single simple node epesents all instances of field f. All allocation sites of each type ae gouped togethe in a common node. Example 2 s t a1: new O p q s a2: new O p.f s.f This is the pointe assignment gaph that would be poduced fom the example code using diffeent settings of pointe analysis paametes. A subset-based analysis is being done in this case, so edges ae diected. Object instances ae distinguished, so sepaate nodes epesent s.f and p.f. Each allocation site is epesented using its own node. t

4 Annotations Java class files may contain optional named attibutes with abitay data. Attibutes can be used to communicate esults of analyses to a vitual machine, JIT compile, o othe optimize. Soot povides an annotation famewok which allows annotations to be associated with classes, fields, methods, o individual statements, and popagated cleanly between its intemediate epesentations. We ae expeimenting with encoding side-effect infomation in attibutes fo use by JIT compiles. Bytecode Soot Annotated Bytecode int getx() { etun this.x; O foo( O p, O q ) { int et = ; while(et>0) { p.f = et; q.f = getx(); et = p.f - 1; etun et; If we can detemine that neithe the wite to q.f no the call to getx() access p.f, then we can move the edundant load and stoe of p.f outside the loop. Such side-effect Side-effect JIT Compile Othe Optimizes analysis is one example client of points-to analysis. Side-effect analysis computes a dependence gaph between statements possibly eading o witing fields. This infomation is used by othe analyses within Soot, such as common subexpession elimination. It can also be encoded in the class file as annotations fo use by a vitual machine, JIT compile, o optimize. Side-effect Infomation in Attibutes 1 w q.f = s = p.f 3 w foo() 4 w foo() = q.f 2 p.f = s w 1. Fo each statement, Spak encodes numbeed nodes epesenting locations ead and witten. Repeated uses of the same efeence use the same node. 2. Nodes epesenting ovelapping sets of locations ae connected in a gaph (dashed lines). Hee, foo() eads locations pointed to by q.f, and wites those pointed to by p.f.

5 Solve In the solve, we expeiment with implementation details which affect efficiency. The solve can collapse stongly connected components and ooted DAGs of simple nodes in the pointe assignment gaph. It can then popagate points-to sets fo simple nodes in a single pass. It must iteatively popagate sets fo field efeence nodes to thei aliases. Respecting declaed types inceases pecision, and pevents blowup in the numbe of aliased field efeences, but educes gaph simplification oppotunities. Implementation of points-to sets has a huge effect on analysis times. We ae investigating altenative implementations such as OBDDs. Native Method Simulato We have developed a famewok which allows dispaate flowinsensitive analyses that must conside the effects of native methods to shae a single libay of simulated native methods. Each native method is epesented by a concete subclass of the Native Method Simulation abstact class, in which the method s effects ae descibed in tems of abstact opeations such as object allocations, assignments, and field Native Method Simulation Abstact Class Native Method Simulations Simulation Dive Abstact Class eads and wites. Each analysis povides an implementation of the abstact class, whee it defines its epesentation of the abstact opeations. Expeiments and Futue Wok We will use Spak to answe these questions: Which pointe analysis paametes ae appopiate fo Java? Which pointe analysis paametes ae appopiate fo diffeent client analyses? Which pointe analysis implementations fit well with which pointe analysis paametes? How can analysis esults be used effectively by JIT compiles? How can analysis esults be communicated secuely to JIT compiles? Spak is available fo othe eseaches to implement thei points-to analyses within it, so that they may be compaed in a common context. It is included in vesion of Soot, available unde the LGPL at

6 Cedits Ondřej Lhoták Feng Qian John Jogensen Lauie Henden Sable Reseach Goup, School of Compute Science McGill Univesity, Monteal, CANADA This wok was funded in pat by NSERC, a Richad H. Tomlinson Fellowship, and an IBM Faculty Development gant.