Strictly declarative specification of sophisticated points-to analyses

Abstract

We present the D framework for points-to analysis of Java programs. D builds on the idea of specifying pointer analysis algorithms declaratively, using Datalog: a logicbased language for defining (recursive) relations. We carry the declarative approach further than past work by describing the full end-to-end analysis in Datalog and optimizing aggressively using a novel technique specifically targeting highly recursive Datalog programs.As a result, D achieves several benefits, including full order-of-magnitude improvements in runtime. We compare D with Lhoták and Hendren's P, which defines the state of the art for context-sensitive analyses. For the exact same logical points-to definitions (and, consequently, identical precision) D is more than 15x faster than P for a 1-call-site sensitive analysis of the DaCapo benchmarks, with lower but still substantial speedups for other important analyses. Additionally, D scales to very precise analyses that are impossible with P and Whaley et al.'s bddbddb, directly addressing open problems in past literature. Finally, our implementation is modular and can be easily configured to analyses with a wide range of characteristics, largely due to its declarativeness.

Application-Only Call Graph Construction

“…We analyzed both the DaCapo benchmark programs, v.2006-10-MR2 [3], and the SPEC JVM 98 benchmark programs [29] with JDK 1.4 (jre1.4.2.11) which is larger than JDK 1.3 used by Lhoták and Hendren [20] and similar to JDK 1.4 used by Bravenboer and Smaragdakis [6]. We also evaluate the soundness of the call graphs generated by Cgc by comparing them to the dynamic call graphs recorded at run time using the *J tool [11].…”

“…For ease of modification and experimentation, Cgc is implemented in Datalog. 3 Cgc uses a pointer analysis that is based on the context-insensitive pointer analysis from the Doop framework [6]. However, the analysis is independent of Datalog, and could be transcribed into Java to be embedded into an analysis framework such as Soot or Wala.…”

“…Doop [6] implements various pointer analysis algorithms for Java programs, all defined declaratively in Datalog. Doop constructs the call graph on-the-fly while computing the points-to sets.…”

“…The key reason is dynamic dispatch: the target of a call depends on the runtime type of the receiver of the call. Because the receiver could have been created anywhere in the program, a sound algorithm must either analyze the whole program [1,6,17,21,34], or make very conservative assumptions about the receiver type (e.g., Class Hierarchy Analysis [9]). Additionally, due to the large sizes of common libraries, whole-program analysis of even trivial programs is expensive [7,27,28].…”

“…Since a dynamic call graph does not represent all possible paths of a program, it does not make sense to use it to evaluate the precision of a static call graph. Therefore, we evaluate precision by comparing against call graphs constructed by whole-program analysis (using both the Spark [20] and Doop [6] call graph construction systems). We also compare the performance of our prototype par-tial call graph construction system with whole-program call graph construction.…”