1 / 18

Refinement-Based Context-Sensitive Points-To Analysis for Java

Refinement-Based Context-Sensitive Points-To Analysis for Java. Manu Sridharan , Rastislav Bodík UC Berkeley PLDI 2006. What Does Refinement Buy You?. Cast Safety Client. Increased scalability : enable new clients Memory : orders of magnitude savings

kyrie
Download Presentation

Refinement-Based Context-Sensitive Points-To Analysis for Java

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Refinement-Based Context-Sensitive Points-To Analysis for Java Manu Sridharan, Rastislav Bodík UC Berkeley PLDI 2006

  2. What Does Refinement Buy You? • Cast Safety Client • Increased scalability: enable new clients • Memory: orders of magnitude savings • Time: answer for a variable comes back in 1 second • )Suitable for IDE • Precision:

  3. Approach: Focus on the Client • Demand-driven: only do requested work • Client-driven refinement: stop when client satisfied • Example: • client asks: “can x point to o?” • we refine until we answer NO (the good answer) or we time out

  4. Context-Sensitive Analysis Costly • Context-sensitive analysis (def): • Compute result as if all calls inlined • But, collapse recursive methods • Exponential blowup (code growth)

  5. Why Not Existing Technique? • Most analyses approximate same way in all code • E.g., k-CFA • Precision lost, esp. for data structures • Our analysis focuses precision where it matters • Fully precise in the limit • Only small amount of code analyzed precisely • First refinement algorithm for Java

  6. Points-To Analysis Overview • Compute objects each variable can point to For each var x, points-to set pt(x) • Model objects with abstract locations 1: x = new Foo()yields pt(x) = { o1 } • Flow-insensitive: statements in any order

  7. Points-To Analysis as CFL-Reachability 1) Assignments x = new Obj(); // o1 y = new Obj(); // o2 z = x; • pt(x) = { o | o flowsTo x } z a o1 x 2) Method calls id(p) { return p; } a = id(x); b = id(y); (1 [f )1 ]f d c pid retid [g )2 (2 3) Heap accesses c.f = x; c.g = y; d = c.f; o2 y b flowsTo: path exists flowsTo: balanced call and field parens flowsTo: balanced call parens

  8. Summary of Formulation • Graph represents program • Compute reachability with two filters • Language of balanced call parens • Language of balanced field parens

  9. Single path problem … … t9 • Problem: show path is unbalanced • Goal: reduce number of visited edges • Insight: enough to find one unbalanced paren t7 ]j [p t8 )8 t6 … t5 (7 )5 (1 )1 o t0 t1 t2 x [h [f t12 ]k [f (1 )1[h ]g o2 t10 t11

  10. Approximation via Match Edges • Match edges connect matched field parens • From source of open to sink of close • Initially, all pairs connected • Use match edges to skip subpaths t4 x o t0 t1 t2 t3 [g ]h [h [f ]j ]f [f[g [h ]h]j ]f

  11. Refining the Approximation • Refine by removing some match edges • Exposes more of original path for checking • Soundness: Traverse match edge )assume field parens balanced on skipped path • Remove where unbalanced parens expected • Explore deeper levels of pointer indirection t4 x o t0 t1 t3 [g [f ]j ]f [f[g [h ]h]j ]f

  12. Refinement With Both Languages (2 )3 )1 (1 o t0 t1 t2 t4 t5 t6 x t3 [g ]g ]f [f Fields: [f [g ]g ]f Calls: (1 )1(2)3 • Match edges enable approximation of calls • Only can check calls on match-free subpaths • Match edge removal )more call checking • Key point: refine heap and calls together

  13. Evaluation

  14. Experimental Configuration • Implemented in Soot framework • Tested on large benchmarks x 2 clients • SPECjvm98, Dacapo suite • Downcast checking, factory method props • Refine context-insensitive result • Timeout for long-running queries

  15. Precision: Cast Checking

  16. Scalability: Time and Memory • Average query time less than 1 second • Interactive performance (for IDE) • At most 13 minutes for casts, 4 minutes for factory client • Very low memory usage: at most 35MB • Of this, 30MB for context-insensitive result • Compare with >2GB for 1-ObjSens analysis

  17. Demand-Driven vs. Exhaustive • Demand advantage: no caching required • Hence, low memory overhead • No engineering of efficient sets • Good for changing code; just re-compute • Demand advantage: faster for many clients • Often only care about some variables • Demand disadvantage: slower querying all vars • At most 90 minutes for all app. vars • But, still good precision, memory

  18. Conclusions • Novel refinement-based analysis • More precise for tested clients • Interactive performance for queries • Low memory: could scale even more • Relatively easy to implement • Insight: refine heap and calls together • Useful for other balanced-paren analyses?

More Related