1. Building a Whole-Program Type Analysis in Eclipse
Mariana Sharp, Jason Sawin,
Atanas (Nasko) Rountev
Ohio State University
Supported by an IBM Eclipse Innovation Grant

2. Eclipse as a Platform for Static Analysis Research
Off-the-shelf infrastructure
Parsing, intermediate representation, etc.
Analysis comparison: apples-to-apples
Analysis integration: exploit synergies
Realistic analyses: no cutting of corners
Challenging issues of integration
Technology transfer
Real-world impact of the research
Nasko Rountev - ETX'05

3. Building a Static Analysis Infrastructure
Challenge: easy-to-use implementations of popular static analyses
Type analysis, call graph construction, side effect analysis, dependence analysis, etc.
Analysis implementations: simple interfaces + sophisticated implementations
Researchers and developers should think of them as parts of the infrastructure
Similarly to the Java compiler, AST builder, …
If you claim you are an expert in a particular static analysis, create a public plug-in for it!
Nasko Rountev - ETX'05

4. TACLE = type analysis and call graph construction for Eclipse
The TACLE Project
TACLE = type analysis and call graph construction for Eclipse
Download at presto.cse.ohio-state.edu/tacle
ICallGraphAnalysis analysis = …
IMethod main = …
analysis.run(main);
Set methods = analysis.getReachableMethods();
for (Iterator i = methods.iterator(); i.hasNext();) {
IMethod m = (IMethod) i.next();
Set callees = analysis.getCalledMethods(m); …
Nasko Rountev - ETX'05

5. Design Goals for Static Analyses
Both for TACLE and for other analyses in Eclipse
Careful handling of library code
Continuous re-computation of analysis solution
Upon every successful re-compilation?
Work in the background, exploit free cycles
Analysis of partial programs
Source code analysis
Use ASTs as the analysis input
Nasko Rountev - ETX'05

6. Whole-Program Rapid Type Analysis
Current implementation of TACLE
Rapid Type Analysis (RTA)
In the future, add points-to analysis
Whole-program RTA
Start from main; compute the set of reachable methods and instantiated types
Simple implementation
Every time a method becomes reachable, construct the AST of the surrounding class
or look it up if already constructed
AST traversal for method body
Nasko Rountev - ETX'05

7. Methods in the Whole-Program Call Graph
Nasko Rountev - ETX'05

8. Whole-Program vs. Summary-Based Analysis
Problem: running time and memory use
AST building and analysis for library code
Problem: unavailability of source code
e.g. parts of the standard libraries in Sun’s J2SE do not have public source code
Solution: pre-computed library summary information; reused many times
One-time summary generation cost
Part of plug-in distribution; or, computed in the user’s environment at deployment
Nasko Rountev - ETX'05

9. Whole-Program vs. Summary-Based RTA in TACLE
Nasko Rountev - ETX'05

10. Whole-Program vs. Summary-Based RTA in TACLE
Nasko Rountev - ETX'05

11. Conclusions and Future Work
If you are building a whole-program analysis in Eclipse, consider using summary information about the standard libraries
Avoid AST building; pre-compute some results
TACLE goals
incomplete call graph and type information
points-to analysis using summary info
side-effect analysis using summary info
summary info for library components other than the standard libraries
continuous analyses on the background
analysis of partial programs (no main)
Nasko Rountev - ETX'05