PRESTO Research Group, Ohio State University Interprocedural Dataflow Analysis in the Presence of Large Libraries Atanas (Nasko) Rountev Scott Kagan Ohio State University Thomas Marlowe Seton Hall University

3/30/06 2 CC 2006, Scott Kagan, PRESTO Research Group Uses of Interprocedural Dataflow Analysis  Performance optimizations in compilers  Software understanding and transformation  e.g. dependence analysis for program slicing, change impact analysis, refactoring, etc.  Software testing  e.g. dataflow-based testing; testing of object interactions in OO software  Software checking  e.g. object protocols: open(read|write)*close

3/30/06 3 CC 2006, Scott Kagan, PRESTO Research Group Model for Interprocedural Whole-Program Analysis  Components C 1, C 2, …, C n form a complete program  Assumption: it is possible and desirable to analyze the source code of the entire program code for C 1 code for C 2 … code for C n dataflow solution for C 1 + C 2 + … + C n Engine for Whole-ProgramDataflowAnalysis

3/30/06 4 CC 2006, Scott Kagan, PRESTO Research Group A Specific Case: Main + Lib  Main + Lib form a complete program  What if we are using large libraries that need to be re- analyzed from scratch?  e.g. the standard Java libraries contain about 10,000 classes and 80,000 methods  need to be re-analyzed with every new Main component code for Main code for Lib dataflow solution for Main + Lib Engine for Whole-ProgramDataflowAnalysis

3/30/06 5 CC 2006, Scott Kagan, PRESTO Research Group Example: Methods in Java Programs

3/30/06 6 CC 2006, Scott Kagan, PRESTO Research Group A Specific Case: Main + Lib  Goal: the solution for Main should be as good as the solution that would have been computed by a whole- program analysis (no loss of precision) code for Lib Summary Generation Analysis summary for Lib code for Main dataflow solution for Main Engine for Whole-Program Dataflow Analysis summary for Lib

3/30/06 7 CC 2006, Scott Kagan, PRESTO Research Group Functional Approach to Whole-Program Analysis  Sharir-Pnueli 1981  Dataflow lattice L  Edge function f: L  L for effects of a statement  Path function: f = f n  f n-1  …  f 2  f 1  Phase 1: summary functions φ n : L  L  solution at node n as a function of the solution at the entry of n’s procedure  Phase 2: solutions at start nodes of procedures  Phase 3: solutions at the remaining nodes

3/30/06 8 CC 2006, Scott Kagan, PRESTO Research Group φ 6 = φ 13  f 1  f 0 Example: Functional Approach φ 28 = f 8  f 7 φ 21 = f 4  f 5  (φ 28  f 6 ) φ 13 = (φ 21  f 2 )  (φ 21  f 3 )

3/30/06 9 CC 2006, Scott Kagan, PRESTO Research Group Callbacks  Callbacks  e.g. function pointers in C  e.g. virtual dispatch in C++ and Java  Can no longer determine φ 21 and φ 13 without code for ext

3/30/06 10 CC 2006, Scott Kagan, PRESTO Research Group Library Summary  Idea: run “pieces” of phase 1  Compute functions for sets of library- local paths φ = id φ = f 8  f 7  f 6 φ = f 4  f 5 φ = f 2  f 3 φ = id

3/30/06 11 CC 2006, Scott Kagan, PRESTO Research Group Library Summary Generation  “Fixed” call in the library  always invokes the same library procedure independent of code for main component  “Fixed” procedure in the library  makes no calls, or  makes only fixed calls, to fixed procedures  standard functional approach can be applied  For any other procedure, compute φ  k is the start node, or  k is a return from a non-fixed call, or  k is a return from a fixed call to a non-fixed procedure knkn

3/30/06 12 CC 2006, Scott Kagan, PRESTO Research Group Example: Library Summary Generation  Fixed calls  and  Non-fixed calls   Fixed procedures  p3  Non-fixed procedures  p1 and p2  Contexts k for φ  7 and 14: start nodes  17: return from a non-fixed call  12: return from a fixed call to a non-fixed procedure knkn

3/30/06 13 CC 2006, Scott Kagan, PRESTO Research Group The Condensed Graph p2 21 p φ = id φ = f 8  f 7  f 6 φ = f 4  f 5 φ = f 2  f 3 φ = id

3/30/06 14 CC 2006, Scott Kagan, PRESTO Research Group Analysis of a Main Component  Create a “fake” graph for the whole program  Run a whole- program analysis engine  Safe solutions for non-library nodes  precise for distributive problems

3/30/06 15 CC 2006, Scott Kagan, PRESTO Research Group Original vs. Condensed Library CFGs: Number of Nodes

3/30/06 16 CC 2006, Scott Kagan, PRESTO Research Group Original vs. Condensed Library CFGs: Number of Edges

3/30/06 17 CC 2006, Scott Kagan, PRESTO Research Group Discussion  Flow and context insensitivity  Cost reduction: time and memory  Compact representation of functions  IFDS, IDE  Use assumptions about the callback methods?  e.g. assume callback methods are “good”