DOC PREVIEW
Berkeley COMPSCI 164 - Lecture 29: Pointer Analysis

This preview shows page 1-2 out of 6 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Lecture 29: Pointer AnalysisGeneral Goals of Static AnalysisClient 1: Optimizing virtual calls in JavaClient 1: ExampleClient 2: Verification of castsClient 2: ExampleClient 3: Non-overlapping fields in heapPointer AnalysisAnalysesFlow analysis as a constant propagationAbstract objectsFlow analysis: Add pointer dereferencesFlow-Insensitive AnalysisFlow-Insensitive Analysis, contd.Canonical StatementsHandling of method calls: Arguments and return valuesHandling of method calls: targets of virtual callsHandling of method calls: arraysAndersen's Algorithm for flow-insensitive points-to analysisStatement factsMeaning of the resultsInference ExampleInference Example, contd.Prolog program for Andersen algorithmLecture 29: Pointer Analysis[Based on slides from R. Bodik]Administrivia• Project due data now 11 May (Monday).• Autograder run Friday.Today• Points-to analysis: an instance of static analysis for understandingpointers• Andersen’s algorithm via deduction• Implementation of Andersen’s algorithm in PrologLast modified: Tue May 5 12:12:45 2009 CS164: Lecture #29 1General Goals of Static Analysis• Determine run-time properties statically at compilation.• Sample property: “is variable x a constant?”• Since we don’t know the inputs, must consider all possible programexecutions.• Conservative (err on the side of caution) forsoundness:– allowed to say x is not a constant when it is,– but not that x is a constant when it is not .• Many clients: optimization, verification, compilation.Last modified: Tue May 5 12:12:45 2009 CS164: Lecture #29 2Client 1: Optimizing virtual calls in Java• Motivation: virtual calls are costly, due to method dispatch• Idea:– determine the target of the call statically– if we can prove call has a single target method, call the targetdirectly• declared (static) types of pointer variables not precise enough forthis, so, analyze their run-time (dynamic) types.Last modified: Tue May 5 12:12:45 2009 CS164: Lecture #29 3Client 1: Exampleclass A { void foo() {...} }class B extends A { void foo() {...} }void bar(A a) { a.foo() }// OK to just call B.foo?B myB = new B();A myA = myB;bar(myA);• Declared type of a permits a.foo() to target both A.foo and B.foo.• Yet we know only B.foo is the target.• What program property would reveal this fact?Last modified: Tue May 5 12:12:45 2009 CS164: Lecture #29 4Client 2: Verification of casts• In Java, casts are checked at run time: (Foo) e translates toif (! (e instanceof Foo))throw new ClassCastException()• Java generics help readability, but still cast.• The exception prevents any security holes, but is expensive.• Static verification useful to catch bugs.• Goal: prove that no exception will happen at runtimeLast modified: Tue May 5 12:12:45 2009 CS164: Lecture #29 5Client 2: Exampleclass SimpleContainer { Object a;void put (Object o) { a=o; }Object get() { return a; } }SimpleContainer c1 = new SimpleContainer();SimpleContainer c2 = new SimpleContainer();c1.put(new Foo()); c2.put(‘‘Hello’’);Foo myFoo = (Foo) c1.get(); // Check not neededWhat property will lead to desired verification?Last modified: Tue May 5 12:12:45 2009 CS164: Lecture #29 6Client 3: Non-overlapping fields in heapE = new Thing (42);for (j = 0; j < D.len; j += 1) {if (E.len >= E.max)) throw new OverflowException ();E.data[E.len] = D.data[i]; E.len += 1;}We assign toE.len, but we don’t have to fetch from D.len every time;can save in register.Last modified: Tue May 5 12:12:45 2009 CS164: Lecture #29 7Pointer Analysis• To serve these three clients, want to understand how pointers “flow,”that is, how they are copied from variable to variable.• Interested in flow fromproducersof objects (new Foo) tousers(myFoo.f).• Complication: pointers may flow via the heap: a pointer may bestored in an object’s field and later be read from this field.• For simplicity, assume we are analyzing Java without reflection, sothat we know all fields of an object at compile time.Last modified: Tue May 5 12:12:45 2009 CS164: Lecture #29 8Analyses• Client 1: virtual call optimization:– which producer expressions new T() produced the values that mayflow to receiverp (a consumer) in a call?– Knowing producers tells us possible dynamic types ofp, and thusalso the set of target methods.• Client 2: cast verification:– Same, but producers include expressions (Type) p.• Client 3: non-overlapping fields: again, same questionLast modified: Tue May 5 12:12:45 2009 CS164: Lecture #29 9Flow analysis as a constant propagation• Initially, consider only new and assignments p=r:if (...) p = new T1(); else p = new T2();r = p; r.f();// what are possible dynamic types of r?• We (conceptually) translate the program toif (...) p = o1; else p = o2;r = p; r.f();// what are possible symbolic constant values r?Last modified: Tue May 5 12:12:45 2009 CS164: Lecture #29 10Abstract objects• Theoiconstants are called abstract objects• an abstract objectoistands for any and all concrete objects allo-cated at theallocation site(‘new’ expression) with number i.• When the analysis says a variablep may have value o7,• we know p may point to any object allocated atnew7Foo()Last modified: Tue May 5 12:12:45 2009 CS164: Lecture #29 11Flow analysis: Add pointer dereferencesx = new Obj();// o1z = new Obj(); // o2w = x;y = x;y.f = z;v = w.f;• To propagate the abstract objects throughp.f, must keep track oftheheap state—where the pointers point:– y and w point to same object– z and y.f point to same object, etc.Last modified: Tue May 5 12:12:45 2009 CS164: Lecture #29 12Flow-Insensitive Analysis• The heap state may change at each statement, so ideally, track theheap state separately at each program point as in dataflow analysis.• But to be scalable (i.e. practical), analyses typically don’t do it.• For example, to save space, can collapse all program points into oneconsequently, they keep a single heap state, and disregard the con-trol flow of the program (flow-insensitiveanalysis):assume that statements can execute in any order, and any numberof times• So, flow-insensitive analysis transforms this programif (...) p = new T1(); else p = new T2();r = p; p = r.f;into this CFG:r = pp = r.fp = new T1()p = new T2()•Last modified: Tue May 5 12:12:45 2009 CS164: Lecture #29 13Flow-Insensitive Analysis, contd.• Motivation: Just “version” of program state, hence less space• Flow-insensitive analysis


View Full Document

Berkeley COMPSCI 164 - Lecture 29: Pointer Analysis

Documents in this Course
Lecture 8

Lecture 8

40 pages

Load more
Download Lecture 29: Pointer Analysis
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 29: Pointer Analysis and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 29: Pointer Analysis 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?