Static and Dynamic Analysis of Call Chains in Java

1
Static and Dynamic Analysis of Call Chains in Java

• Atanas Rountev
• Scott Kagan
• Michael Gibas
• Ohio State University

2
Call Chains

• Sequence of call graph edges
• lte1, e4gt, lte1, e4, e3gt, lte2, e3gt, etc

e2
X.m()
X.n()
e1
e3
e4
Y.p()
X.o()
3
Analysis of Call Chains

• Static analysis
• Input static call graph
• Output set of static call chains
• Dynamic analysis
• Input set of static call chains
• Output run-time coverage of the chains

4
Uses of Call Chain Information

• Software Understanding
• Reverse engineering of UML sequence diagrams
• Original motivation
• Code browsing
• Sequences of calls that may lead to a method
  being executed
• Software Testing
• Coverage of interesting chains
• Integration testing
• Object interactions

5
Our Work

• Defined an approach for static and dynamic
  analysis of call chains in Java components
• Performed an experimental evaluation of the
  imprecision of static call chain analysis

6
Static Analysis Input

• Component and static call graph
• Component set of classes
• Static call graph for the component
• Entry methods

X.m()
X.n()
c2,X
c1,X
c3,Y
c4,Y
Y.p()
X.o()
7
Static Analysis Output

• Data structure which represents a set of call
  chains
• Based on calling context tree
• Ammons et al., PLDI 1997
• Nodes correspond to procedures
• Edges correspond to calling relationships
• Each node represents a chain
• Statically built
• Represents a component, not a program
• Calling context forest

8
Example
X.m()
c1,X
c2,X
X.o()
X.n()
c4,Y
c3,Y
Y.p()
X.n()
c3,Y
Y.p()
9
Forest Construction

• Traverse call graph
• Stopping mechanism
• Limit depth
• Filter infeasible chains
• Calls through implicit formal parameter this

10
Dynamic Analysis

• Input calling context forest and an executable
  that contains the component
• Goal traverse forest, visit nodes
• Obvious application chain coverage
• Traversal can be in different states
• Start not yet entered component
• Active currently traversing forest
• Limited tree node not present
• External left component, waiting to return
• Instrument component code

11
Instrumentation

• Generate run-time events
• entered(m)
• m is an entry method
• Entering component code
• exited(m)
• Exiting component code
• before(c, X)
• c is call site, X is receiver class
• after(c, X)
• c is call site, X is receiver class
• Instrumentation localized

12
Limitations

• No exceptions are thrown
• Developed solution
• Single threaded execution
• Static and dynamic checks to ensure constraints

13
Basic Example
X.m()
Event entered(X.m) before(c2,X) before(c3,Y) befor
e(c5,Z) after(c5,Z) after(c3,Y) after(c2,X) exited
(X.m)
State Start Active Limited External Limited Active
Start
c2,X
c1,X
X.o()
X.n()
Counter 1 0
Previous State Limited
14
Our Work

• Defined an approach for static and dynamic
  analysis of call chains in Java components
• Performed an experimental evaluation of the
  imprecision of static call chain analysis

15
Experimental Evaluation

• Chains are statically constructed
• Some chains may be infeasible
• What is the degree of imprecision?
• What are the causes of imprecision?
• Ultimate goal better static analysis

16
Analysis Implementation

• Soot framework (www.sable.mcgill.ca)
• Input a component and set of tests
• Output call chains coverage
• Call graph construction
• Fragment analysis (Rountev et al., TSE 2004)
• Placeholder main method
• RTA, Andersens style points-to analysis
• Static Analysis
• Infeasibility filter, depth-limited chains

17
Degree of Imprecision

• Open source set of tests for Java standard
  library classes
• Formed 6 components
• Average 101 methods
• Determined run-time coverage of statically
  computed call chains
• Were uncovered chains feasible or infeasible?
• Enhanced test suite for maximal coverage
• Uncovered chains from enhanced test suite were
  infeasible

18
(No Transcript)
19
Cause of Imprecision Experiment

• Approximations made by the static analysis
• if (flag) x.foo()
• Abstracted semantics
• All branches of non-reference conditions possible
• Otherwise, same as regular Java semantics
• What if infeasible chains are feasible in new
  semantics?
• Imprecision in any static analysis with same
  approximation
• For all components, 94.5 of infeasible chains
  were feasible in new semantics

20
Future Work

• Exceptions
• no new states, only new instrumentation
• Multi-threading
• Increase data sets
• Study more causes of infeasibility
• Speed optimized implementation