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

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

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

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

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

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

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

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 1.4.2 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

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

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

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