110 likes | 220 Views
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
E N D
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
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