CS 343 presentation Concrete Type Inference Department of Computer Science Stanford University

Concrete type analysis… why we care Runtime cost of virtual method resolution is high Reduction of code size Call graphs needed for interprocedural analysis Function inlining Inference algorithms very expensive – coming up with efficient algorithms is the challenge

Fast Static Analysis of C++ Virtual Function Calls Bacon and Sweeney

Overview Goal: Resolving virtual function calls Three Static analysis algorithms –Unique name –Class Hierarchy Analysis (CHA) –Rapid Type Analysis (RTA)

Example class A{ public: virtual int foo(){return 1;}; } class B: public A { public: virtual int foo(){return 2;}; virtual int foo(int t){return I+1}; } void main(){ b* p = new B(); int result1 = p-> foo(1); int result2 = p->foo(); A* q = p; int result3 = q->foo(); } A B int foo() int foo(int)

Unique Name Link time process Doesn’t require access to source code Checks mangled name Unique signature implies replacing virtual call with direct call

Class Hierarchy Uses static declared type with class hierarchy information Builds call graph Replaces virtual calls with direct calls when there are no derived classes for the static type Rely on type safety of language (sometimes need to disable downcasts)

Rapid Type Analysis Starts with call graph generated from CHA Prunes the size the call graph based on static information about class instantiation Flow insensitive like CHA –results in efficiency –Inherits limitations of flow insensitive analysis  Rely on type safety of language (sometimes need to disable downcasts)

Results What biases the results? (C++) Ran analysis algorithms on seven real programs of varying size (large - small) RTA wins 4 out of 7 WHY? Discuss Static analysis can fail with certain programming idioms (e.g. base*b = new sub() ) Code Size: often reduces code size dramatically

Practical Virtual Method Call Resolution for Java Sundaresan et al

Overview Study practical, context-insensitive, flow insensitive techniques to resolve virtual function calls in Java Present Reaching-type analysis –Variable-type analysis –Refers-to analysis Uses Soot(Jimple) framework

Three Groups of analysis Baseline (discussed previously) –Class hierarchy analysis –Rapid type Analysis Reaching type –Declared type analysis –Variable type analysis (more fine grain/accurate) Refers-to –Developed for C but ported to

Reaching-type Analysis Build a type propagation graph Initialize the graph with type information generated by new() Propagate type information along directed edges Nodes are associated with all reaching types

Variable and Declared Type Analysis Variable Type (pg 10) –Uses variable name as the representative Declared Type (pg 11) –Uses the type by which the initial variable was declared –Puts all variables of the same declared type into the same equivalence class –Coarser and less precise Both algorithms have an initialization phase and an propagation phase Size of propagation graph: O(C*M c ) edges

Refers-to Analysis Takes into account aliasing Nodes –Reference nodes (locals, parameters, instance fields) –Abstract location nodes (heap locations) Algorithm: Each reference node initially refers to a unique abstract location, assignments merge abstract locations as the algorithm progresses

Alternative Approaches Type prediction –Requires profiling code –Making the common case fast –Runtime type test –Resolves more calls Alias analysis –Very expensive (interprocedural, flow sensitive) Sometimes static analysis is not possible e.g. dynamically loaded classes based on command line inputs or newly available classes.  Does anyone see a way to address this?

Benchmarks and Results Ran on 9 programs, 7 of which are used in the SPECjvm benchmark suite Variable type analysis best at improving call graph precision Type based analysis more efficient because it build nodes based on the classes in the program and not each individual variable Table II shows exact numbers for how many monomorphic edges…. So why couldn’t they resolve all of these? How did they get this information in the first place???

“The Cartesian Product Algorithm” Simple and Precise Type Inference of Parametric Polymorphism

Polymorphism Explicit concrete type declarations undesirable for programmer Algorithms must be used to infer types Parametric polymorphism: ability of routines to be invoked on arguments of several different types CPA uses context sensitivity, whereas other inference algorithms do not, this is key b/c CPA uses different code for each context

Basic Type Inference Algorithm Step 1: Allocate type variables (associate a type var with every slot and expression in the program) Step 2: Seed type variables (to capture the initial state of the target program) Step 3: Establish constraints, propagate (builds a directed graph that expresses propagation of types through assignments) Basic algorithm analyzes polymorphism imprecisely

Improvements on Basic Algorithm 1-Level Expansion –Different templates for each send –Inefficient P-Level (precise, yet worst-case complexity is exponential) Iterative algorithm (precise, more efficient than expansion)

Cartesian Product Algorithm “There is no such thing as a polymorphic call, only polymorphic call sites” Turns the analysis of each send into a case analysis (makes exact type info available for each case immediately, eliminates iteration) Maintain per-method pools of templates so that template-sharing can be achieved (efficiency) Iteration is avoided because of –Monotonicity of cartesian product –Monotone context of application (iterative is not monotone because comparing types for equality is not a monotone function) Efficient and precise (also, no need to expand away inheritance)

Precision improvements possible? Yes mod arg = (self-(arg*(self div: arg) ) x mod: y, where type(x) = type(y) = {smallInt, float} Iterative algorithm infers {smallInt, float} CPA infers {smallInt} In this case, there is a benefit from having four templates connected, one for each tuple in the product of the types of x and y

Results “Extractor” – having less precise information about type forces it to extract more CPA delivers the smallest extractions, and the best CPU time of the different algorithms How generalizable are the results from the Self system? How much type inference is even necessary for the programs they benchmarked (Unix diff command)?

Thanks caller callee