Accelerating Program Analyses in Datalog by Merging Library Facts

Abstract

Static program analysis uses sensitivity to balance between precision and scalability. However, finer sensitivity does not necessarily lead to more precise results but may reduce scalability. Recently, a number of approaches have been proposed to finely tune the sensitivity of different program parts. However, these approaches are usually designed for specific program analyses, and their abstraction adjustments are coarse-grained as they directly drop sensitivity elements.

In this paper, we propose a new technique, 4DM, to tune abstractions for program analyses in Datalog. 4DM merges values in a domain, allowing fine-grained sensitivity tuning. 4DM uses a data-driven algorithm for automatically learning a merging strategy for a library from a training set of programs. Unlike existing approaches that rely on the properties of a certain analysis, our learning algorithm works for a wide range of Datalog analyses. We have evaluated our approach on a points-to analysis and a liveness analysis, on the DaCapo benchmark suite. Our evaluation results suggest that our technique achieves a significant speedup and negligible precision loss, reaching a good balance.

Appendices

A Incremental Merging in N-Domain-Wise Cases

Here we describe how to define an incremental merging function for general cases of N-domain-wise merging.

Suppose we want to define a merging function on N domains $D_1, D_2, \ldots , D_N$. Without loss of generality, we suppose $D_i$ can only be a super-domain of $D_j$ when $i > j$. We define $\pi _i$ ($1 \le i \le N$) by induction:

• When $i = 1$, we can define an arbitrary 1-domain-wise merging function on $D_1$.

• Suppose we have defined a function $\pi _i : D_1\times \dots \times D_i \rightarrow \widehat{D_{1\ldots i}}$, we can define $\pi _{i+1} : D_1\times \dots \times D_i\times D_{i+1} \rightarrow \widehat{D_{1\ldots i+1}}$ with a helper function $\pi _{i+1}'$:

  $$\begin{aligned} \pi _{i+1}' : \widehat{D_{1\ldots i}} \times \widehat{D_{i+1}} \rightarrow \widehat{D_{1\ldots i+1}} \end{aligned}$$

  Here $\widehat{D_{i+1}}$ represents the changed domain of original $D_{i+1}$ after applying the merging $\pi _i$, and $\pi _{i+1}(d_1,\ldots ,d_i,d_{i+1}) = \pi _{i+1}'(\pi _i(d_1, \ldots , d_i), \pi _i(d_{i+1}))$. Note that $\pi _i(d_{i+1})$, which $d_{i+1}$ would become under $\pi _i$, is determined after applying $\pi _i$ to the Datalog program.

With $\pi = \pi _N$, we get an N-domain-wise merging function on $D_1 \times \dots \times D_N$.

B Proof: The Monotonicity of Mergings

Theorem 3 (Monotonicity)

Given a Datalog program C. If the merging $\pi _b$ of the domains $D_1, \dots , D_N$ is a finer merging than $\pi _a$, then applying $\pi _b$ to C will deduce no fewer results than $\pi _a$. It means

Proof

Given a Datalog program C, any derivation on the proof tree in has the form

$$\begin{aligned} R^0(\varPi _a(d^0_1), \varPi _a(d^0_2), \ldots ) :\,\!:= \ldots , R^j(\varPi _a(d^j_1), \varPi _a(d^j_2), \ldots ), \ldots . \end{aligned}$$

(note that the concrete values $\{d^j_i\}$ may not originally match with each other, but get matched after applying $\varPi _a$).

As is defined, for any domain D, $\forall x,y\in D, \varPi _a(x) = \varPi _a(y) \rightarrow \varPi _b(x) = \varPi _b(y)$, so in ’s proof tree,

$$\begin{aligned} R^0(\varPi _b(d^0_1), \varPi _b(d^0_2), \ldots ) :\,\!:= \ldots , R^j(\varPi _b(d^j_1), \varPi _b(d^j_2), \ldots ), \ldots . \end{aligned}$$

also holds as a renaming of the previous instantiation.

Therefore, .

C Detailed Performance of 4DM in Points-to Analysis on Large Projects

Table 2 presents the performance of 4DM by applying learnt heuristics from small projects to large projects. Each column of 4DM shows the result of applying a heuristic learnt from a training set of 12 projects. The partition of training set is the same as in Sect. 6.1.

Table 2. Performance of applying heuristics learnt by 4DM from small projects to large projects.

D Detailed Performance of 4DM in Liveness Analysis

Table 3 shows the detailed results of applying 4DM to liveness analysis.

One practical concern in evaluation is that liveness analysis is usually very fast, hence random events in the processor could have a big influence on the measured run time of compiled executable. We tackle this problem by using Soufflé interpreter to run the analysis and obtain a more reliable record of analysis time.

We use a T-test to check whether the distribution of analysis time changes significantly after merging. The smaller the p-value, the stronger the evidence that two distributions are different. We perform 50 independent runs for each benchmark and analysis. The analysis time is the average of the 50 runs, and the p-value is calculated base on these data.

We measure the precision by the size of calculated live-variable set at all call sites. Note that since our approach is sound, this property is non-decreasing; and the less the size increases, the more precise the analysis is.

Table 3. Performance for liveness analysis. lib1 = {luindex, sunflow, hsqldb}, lib2 = {avrora, batik, bloat}, lib3 = {chart, lusearch, pmd}.