Interprocedural Data Flow Analysis in Soot using Value Contexts

Figure 1 provides the overall algorithm. Line 1 declares three globals: a set of contexts that have been created, a transition table mapping a context and call site of a caller method to a target context at the called method and a work-list of context-parametrized control-flow graph nodes whose flow function has to be processed.

The procedure initContext (lines 2-11) initializes a new context with a given method and entry value. The exit value is initialized to the $\top$ element. IN/OUT values at all nodes in the method body are also initialized to $\top$, with the exception of the method’s entry node, whose IN value is initialized to the context’s entry value. All nodes of this context are added to the work-list.

The doAnalysis procedure (lines 12-51) first creates a value context for the main method with some boundary information (BI). Then, data flow analysis is performed using the traditional work-list method, but distinguishing between nodes of different contexts.

A node is removed from the work-list and its IN value is set to the meet of the OUT values of its predecessors (lines 16-21). For nodes without a method call, the OUT value is computed using the normal flow function (line 37). For call nodes, parameter passing is handled by a call-entry flow function that takes as input the IN value at the node, and the result of which is used as the entry value at the callee context (lines 24-26). The transition from caller context and call-site to callee context is also recorded (line 27). If a context with the target method and computed entry value has not been previously created, then it is initialized now (line 34). Otherwise, the exit value of the target context is used as the input to a call-exit flow function, to handle returned values. A separate call-local flow function takes as input the IN value at the call node, and propagates information about local variables. The results of these two functions are merged into the OUT value of the call node (lines 29-32).

Once a node is processed, its successors are added to the work-list if its OUT value has changed in this iteration (lines 39-43). If the node is the exit of its procedure (lines 44-49), then the exit value of its context is set and all its callers are re-added to the work-list.

The termination of the algorithm follows from the monotonicity of flow functions and the finiteness of the lattice (which bounds the descending chain as well as the number of value contexts).

The algorithm can easily be extended to handle multiple entry/exit points per procedure as well as virtual method calls by merging data flow values across these multiple paths. It can also be easily adapted for backward data flow analyses.

Consider the program in Figure 2 (a), for which we wish to perform a simplified sign analysis, to determine whether a scalar local variable is negative, positive or zero. The call from main to f at $c_{1}$ will only return when the mutual recursion of f and g terminates, which happens along the program path $n_{2}n_{3}n_{4}n_{5}$. Notice that the arguments to f at call-site $c_{3}$ are always of opposite signs, causing the value of variable $c$ to be negative after every execution of $n_{3}$ in this context. Thus, f and hence g always returns a negative value.

To compute this result using the algorithm described above, we use data flow values that are elements of the lattice in Figure 2 (b), where $\top$ indicates an uninitialized variable and $\bot$ is the conservative assumption. We use superscripts to map variables to a sign or $\bot$, and omit uninitialized variables.

At the start of the program no variables are initialized and hence the analysis starts with the initial value context $X_{0}=\langle\texttt{main},\top\rangle$. For work-list removal, we will use lexicographical ordering of contexts (newer first) before nodes (reverse post-order).

The flow function of $\langle X_{0},n_{1}\rangle$ is processed first, which makes $p$ positive (written as $p^{+}$). The next node picked from the work-list is $c_{1}$, whose call-entry flow function passes one positive and one negative argument to parameters $a$ and $b$ of procedure f respectively. Thus, a new value context $X_{1}=\langle\texttt{f},a^{+}b^{-}\rangle$ is created and the transition $\langle X_{0},c_{1}\rangle\rightarrow X_{1}$ is recorded.

Analysis proceeds by processing $\langle X_{1},n_{2}\rangle$ and then $\langle X_{1},c_{2}\rangle$, which creates a new value context $X_{2}=\langle\texttt{g},u^{+}\rangle$ due to the positive argument. The transition $(X_{1},c_{2})\rightarrow X_{2}$ is recorded. When $\langle X_{2},c_{3}\rangle$ is processed, the arguments to f are found to be negative and positive respectively, creating a new value context $X_{3}=\langle\texttt{f},a^{-}b^{+}\rangle$ and a transition $(X_{2},c_{3})\rightarrow X_{3}$.

The work-list now picks nodes of context $X_{3}$, and when $\langle X_{3},c_{2}\rangle$ is processed, the entry value at g is $u^{+}$, for which a value context already exists – namely $X_{2}$. The transition $\langle X_{3},c_{2}\rangle\rightarrow X_{2}$ is recorded. The exit value of $X_{2}$ is at the moment $\top$ because its exit node has not been processed. Hence, the call-exit flow function determines the returned value to be uninitialzed and the OUT of $\langle X_{3},c_{2}\rangle$ gets the value $a^{-}b^{+}$. The next node to be processed is $\langle X_{3},n_{3}\rangle$, whose flow function computes the sign of $c$ to be negative as it is the product of a negative and positive value. The IN value at $\langle X_{3},n_{4}\rangle$ is ($a^{-}b^{+}c^{-}\sqcap a^{-}b^{+})=a^{-}b^{+}c^{-}$. Thus, the sign of the returned variable $c$ is found to be negative. As $n_{4}$ is the exit node of procedure f, the callers of $X_{3}$ are looked up in the transition table and added to the work-list.

The only caller $\langle X_{2},c_{3}\rangle$ is now re-processed, this time resulting in a hit for an existing target context $X_{3}$. The exit value of $X_{3}$ being $a^{-}b^{+}c^{-}$, the returned variable $v$ gets a negative sign, which propagates to the exit node $n_{6}$. The callers of $X_{2}$, namely $\langle X_{1},c_{2}\rangle$ and $\langle X_{3},c_{2}\rangle$, are re-added to the work-list.

$\langle X_{3},c_{2}\rangle$ is processed next, and this time the correct exit value of target context $X_{2}$, which is $u^{+}v^{-}$, is used and the OUT of $\langle X_{3},c_{2}\rangle$ is set to $a^{-}b^{+}c^{-}$. When its successor $\langle X_{3},n_{4}\rangle$ is subsequently processed, the OUT value does not change and hence no more nodes of $X_{3}$ are added to the work-list. Analysis continues with nodes of $X_{1}$ on the work-list, such as $\langle X_{1},c_{2}\rangle$ and $\langle X_{1},n_{3}\rangle$. The sign of $c$ is determined to be negative and this propagates to the end of the procedure. When exit node $\langle X_{1},n_{5}\rangle$ is processed, the caller of $X_{1}$, namely $\langle X_{0},c_{1}\rangle$, is re-added to the work-list. Now, when this node is processed, $q$ is found to be negative.

Value-based contexts are not only useful in terminating the analysis of recursive procedures, as shown above, but also as a simple cache table for distinct call sites. For example, when $\langle X_{0},c_{4}\rangle$ is processed, the positive argument results in a hit for $X_{2}$, and thus its exit value is simply re-used to determine that $r$ is negative. Figure 2 (b) lists the value contexts for the program and Figure 2 (c) shows the transitions between contexts at call-sites.

A context-insensitive analysis would have merged signs of $a$ and $b$ across all calls to f and would have resulted in a $\bot$ value for the signs of $c$, $v$, $q$ and $r$. Our context-sensitive method ensures a precise data flow solution even in the presence of recursion.

Notice that the flow function for $n_{3}$ is non-distributive since $f_{n_{3}}(a^{+}b^{-})\sqcap f_{n_{3}}(a^{-}b^{+})=a^{+}b^{-}c^{-}\sqcap a^{-}b^{+}c^{-}=a^{\bot}b^{\bot}c^{-}$ but $f_{n_{3}}(a^{+}b^{-}\sqcap a^{-}b^{+})=f_{n_{3}}(a^{\bot}b^{\bot})=a^{\bot}b^{\bot}c^{\bot}$. Hence this problem does not fit in the IFDS/IDE framework, but such flow functions do not pose a problem to our algorithm.

We have implemented a flow and context-sensitive points-to analysis using our interprocedural framework to build a call graph on-the-fly. This analysis is both a demonstration of the use of our framework as well as a proposed solution for better call graphs intended for use by other interprocedural analyses.

The data flow value used in our analysis is a points-to graph in which nodes are allocation sites of objects. We maintain two types of edges: $x\rightarrow m$ indicates that the root variable $x$ may point to objects allocated at site $m$, and $m.f\rightarrow n$ indicates that objects allocated at site $m$ may reference objects allocated at site $n$ along the field $f$. Flow functions add or remove edges when processing assignment statements involving reference variables. Nodes that become unreachable from root variables are removed. Type consistency is maintained by propagating only valid casts.

The points-to graphs at each statement only maintain objects reachable from variables that are local to the method containing the statement. At call statements, we simulate assignment of arguments to locals of the called method, as well as the assignment of returned values to a local of the caller method. For static fields (and objects reachable from them) we maintain a global flow-insensitive points-to graph. For statements involving static loads/stores we operate on a temporary union of local and global graphs. The call graph is constructed on-the-fly by resolving virtual method targets using type information of receiver objects.

Points-to information cannot be precise for objects returned by native methods, and for objects shared between multiple threads (as our analysis is flow-sensitive). Thus, we introduce the concept of a summary node, which represents statically unpredictable points-to information and is denoted by the symbol $\bot$. For soundness, we must conservatively propagate this effect to variables and fields that involve assignments to summary nodes. The rules for summarization along different types of assignment statements are as follows:

The last rule is drastically conservative; for soundness we must assume that a call to an unknown procedure may modify the fields of arguments in any manner, and return any object. An important discussion would be on what constitutes an unknown procedure. Native methods primarily fall into this category. In addition, if $p$ is a virtual method invoked on a reference variable $y$ and if $y\rightarrow\bot$, then we cannot determine precisely what the target for $p$ will be. Hence, we consider this call site as a default site, and do not enter the procedure, assuming worst-case behaviour for its arguments and returned values. A client analysis using the resulting call graph with our framework can choose to do one of two things when encountering a default call site: (1) assume worst case behaviour for its arguments (eg. in liveness analysis, assume that all arguments and objects reachable from them are live) and carry on to the next statement, or (2) fall-back onto Soot’s default call graph and follow the targets it gives.

A related approach partitions a call graph into calls from application classes and library classes Ali and Lhoták [2012]. Our call graph is partitioned into call sites that we can precisely resolve to one or more valid targets, and those that cannot due to statically unpredictable factors.

Table 1 lists the results of points-to analysis performed on seven benchmarks. The experiments were carried out on an Intel Core i7-960 with 19.6 GB of RAM running Ubuntu 12.04 (64-bit) and JDK version 1.6.0_27. Our single-threaded analysis used only one core.

The first two columns contain the names of the benchmarks; five of which are the single-threaded programs from the SPEC JVM98 suite spe , while the last two are from the DaCapo suite Blackburn et al. [2006] version 2006-10-MR2. The third column contains the time required to perform our analysis, which ranged from a few seconds to a few minutes. The fourth and fifth columns contain the number of methods analyzed (total and application methods respectively). The next two columns contain the number of value-contexts created, with the average number of contexts per method in the subsequent two columns. It can be seen that the number of distinct data flow values reaching a method is not very large in practice. As our analysis ignores paths with method invocations on null pointers, it was inappropriate for other benchmarks in the DaCapo suite when using stub classes to simulate the suite’s reflective boot process.

The use of default sites in our call graph has two consequences: (1) the total number of analyzed methods may be less than the total number of reachable methods and (2) methods reachable from default call sites (computed using spark’s call graph) cannot be soundly optimized by a client analysis that jumps over these sites. The last column lists the number of clean methods which are not reachable from default sites and hence can be soundly optimized. In all but two cases, the majority of application methods are clean.

In order to highlight the benefits of using the resulting call graph, just listing the number of edges or call-sites alone is not appropriate, as our call graph is context-sensitive. We have thus computed the number distinct paths in the call graph, starting from the entry point, which are listed in Table 2. As the total number of call graph paths is possibly infinite (due to recursion), we have counted paths of a fixed length length $k$, for $1\leq k\leq 10$. For each benchmark, we have counted these paths using call graphs constructed by our Flow and Context-sensitive Pointer Analysis (fcpa) as well as spark, and noted the difference as percentage savings ($\Delta\%$) from using our context-sensitive call graph. The option implicit-entry was set to false for spark.

The savings can be clearly observed for $k>5$. For $k=10$, spark’s call graph contains more than 96% spurious paths for three of the benchmarks, and 62-92% for the remaining. The gap only widens for larger values of $k$ (for which the number of paths was too large to compute in some cases).

Client analyses using our interprocedural framework can be configured to use our context-sensitive call graphs which avoid these spurious paths, hence enabling efficient and precise solutions.