An Ahead-of-time Yet Context-Sensitive Points-to Analysis for Java

At each program point, points-to analysis for statically typed object oriented programming languages (e.g., Java, C++) determines those objects to which a reference may refer (or a pointer may point) during execution. Points-to analysis is necessary for any semantics based software tools for object oriented systems. Our new complexity results for points-to analysis distinguish the difficulty of intraprocedural and interprocedural points-to analyses for languages with combinations of single-level types (i.e., types with data members only of primitive type), exceptions with or without subtyping, and dynamic dispatch. Our results include: 1) the first polynomial-time algorithm for points-to analysis in the presence of exceptions that handles a robust subset of Java without threads and can be applied to C++; 2) proof that the above algorithm is safe, in general, and provably precise on programs with single-level types and exceptions without subtyping, but not dynamic dispatch, thus, this case is in P; 3) proof that an interprocedural points-to analysis problem with single-level types and exceptions with subtyping, but without dynamic dispatch, is PSPACE-hard, while the intraprocedural problem is PSPACE-complete. Other complexity characterizations of points-to analysis in programs without exceptions are presented, including an algorithm with worst-case bound of O(n/sup 5/), which improves over the O(n/sup 7/) worst-case bound achievable from previous approaches of T. Reps et al. (1995) and W.A. Landi and B.G. Ryder (1991).

Points-to analysis is a static program analysis aiming at analyzing the reference structure of dynamically allocated objects at compile-time. It constitutes the basis for many analyses and optimizations in software engineering and compiler construction. Sparse program representations, such as Whole Program Points-to Graph (WPP2G) and Points-to SSA (P2SSA), represent only dataflow that is directly relevant for points-to analysis. They have proved to be practical in terms of analysis precision and efficiency. However, intra-procedural control flow information is removed from these representations, which sacrifices analysis precision to improve analysis performance. We show an approach for keeping control flow related information even in sparse program representations by representing control flow effects as operations on the data transferred, i.e., as dataflow information. These operations affect distinct paths of the program differently, thus yielding a certain degree of path-sensitivity. Our approach works with both WPP2G and P2SSA representations. We apply the approach to P2SSA-based and flow-sensitive points-to analysis and evaluate a context-insensitive and a context-sensitive variant. We assess our approach using abstract precision metrics. Moreover, we investigate the precision improvements and performance penalties when used as an input to three source-code-level analyses: dead code, cast safety, and null pointer analysis.

This paper presents a context-sensitive and path-sensitive, intra-thread and inter-thread solution to combined pointer analysis, escape analysis and data dependence analysis of multithreaded Java programs which uses a sparse representation. We build and maintain a complete Static Single Assignment (SSA) form even for fields variables. We show how to compute inter-thread dependencies for multithreaded programs with structured fork-join constructs, open-ended threads, recursively generated threads, monitors, and wait-notify synchronization. We have implemented our algorithm in a slicer for Java programs. Our experimental results show that a sparse representation improves the analysis time and strong updates on field variables improves the precision.

Static analysis is a popular method to find bugs. In context-sensitive static analysis the analyzer considers the calling context when evaluating a function call. This approach makes it possible to find bugs that span across multiple functions. In order to find those issues the analyzer engine requires information about both the calling context and the callee. Unfortunately the implementation of the callee might only be available in a separate translation unit or module. In these scenarios the analyzer either makes some assumptions about the behavior of the callee (which may be unsound) or conservatively creates a program state that marks every value that might be affected by this function call. In this case the marked value becomes unknown which implies significant loss of precision.In order to mitigate this overapproximation, a common approach is to assign a summary to some of the functions, and each time the implementation is not available, use the summary to analyze the effect of the function call. These summaries are in fact approximations of the function implementations that can be used to model some behavior of the called functions in a given context. The most proper way to represent summaries, however, remains an open question.This paper describes a method for summarising C (or C++) functions in C (or C++) itself. We evaluate the advantages and disadvantages of this approach. It is challenging to use source language representation efficiently due to the compilation model of C/C++. We propose an efficient solution. The emphasis of the paper is on using static analysis to find errors in the programs, however the same approach can be used to optimize programs or any other tasks that static analysis is capable of. Our proof of concept implementation is available in the upstream version of the Clang compiler.

Probabilistic points-to analysis is an analysis technique for defining the probabilities on the points-to relations in programs. It provides the compiler with some optimization chances such as speculative dead store elimination, speculative redundancy elimination, and speculative code scheduling. Although several static probabilistic points-to analysis techniques have been developed for C language, they cannot be applied directly to Java because they do not handle the classes, objects, inheritances and invocations of virtual methods. In this paper, we propose a context-insensitive and flow-sensitive probabilistic points-to analysis for Java (JPPA) for statically predicting the probability of points-to relations at all program points (i.e., points before or after statements) of a Java program. JPPA first constructs an interprocedural control flow graph (ICFG) for a Java program, whose edges are labeled with the probabilities calculated by an algorithm based on a static branch prediction approach, and then calculates the probabilistic points-to relations of the program based upon the ICFG. We have also developed a tool called Lukewarm to support JPPA and conducted an experiment to compare JPPA with a traditional context-insensitive and flow-sensitive points-to analysis approach. The experimental results show that JPPA is a precise and effective probabilistic points-to analysis technique for Java.Keywordspoints-to analysisprobabilityJava

Modern society is irreversibly dependent on computers and, consequently, on software. However, as the complexity of programs increase, so does the number of defects within them. To alleviate the problem, automated techniques are constantly used to improve software quality. Static analysis is one such approach in which violations of correctness properties are searched and reported. Static analysis has many advantages, but it is necessarily conservative because it symbolically executes the program instead of using real inputs, and it considers all possible executions simultaneously. Being conservative often means issuing false alarms, or missing real program errors. Pointer variables are a challenging aspect of many languages that can force static analysis tools to be overly conservative. It is often unclear what variables are affected by pointer-manipulating expressions, and aliasing between variables is one of the banes of program analysis. To alleviate that, a common solution is to allow the programmer to provide annotations such as declaring a variable as unaliased in a given scope, or providing special constructs such as the never-null pointer of Cyclone. However, programmers rarely keep these annotations up-to-date. The solution is to provide some form of pointer analysis, which derives useful information about pointer variables in the program. An appropriate pointer analysis equips the static tool so that it is capable of reporting more errors without risking too many false alarms. This dissertation proposes a methodology for pointer analysis that is specially tailored for modular bug finding. It presents a new analysis space for pointer analysis, defined by finer-grain dimensions of precision, which allows us to explore and evaluate a variety of different algorithms to achieve better trade-offs between analysis precision and efficiency. This framework is developed around a new abstraction for computing points-to sets, the Assign-Fetch Graph, that has many interesting features. Empirical evaluation shows promising results, as some unknown errors in well-known applications were discovered.

Many program analyses benefit, both in precision and performance, from precise pointer analysis. An important dimension of pointer analysis precision is flow-sensitivity, which has been shown to be useful for applications such as program verification and static analysis of binary code, among many others. However, flow-sensitive pointer analysis has historically been unable to scale to programs with millions of lines of code. We present a new flow-sensitive pointer analysis algorithm that is an order of magnitude faster than the existing state of the art, enabling for the first time flow-sensitive pointer analysis for programs with millions of lines of code. Our flow-sensitive algorithm is based on a sparse representation of program code created by a staged, flow-insensitive pointer analysis. We explain how this new algorithm is a member of a new family of pointer analysis algorithms that deserves further study.

Ahstract-Points-to analysis is a fundamental, but computationally intensive technique for static program analysis, optimization, debugging and verification. Context-Free Language (CFL) reachability has been proposed and widely used in demand-driven points-to analyses that aims for computing specific points-to relations on demand rather than all variables in the program. However, CFL-reachability-based points-to analysis still faces challenges when applied in practice especially for flow-sensitive points-to analysis, which aims at improving the precision of points-to analysis by taking account of the execution order of program statements. We propose a scalable approach named Parseeker to parallelize flow-sensitive demand-driven points-to analysis via CFL-reachability in order to improve the performance of points-to analysis with high precision. Our core insights are to (1) produce and process a set of fine-grained, parallelizable queries of points-to relations for the objective program, and (2) take a CFL-reachability-based points-to analysis to answer each query. The MapReduce is used to parallelize the queries and three optimization strategies are designed for further enhancing the efficiency.

The specification language is a critical component of the hardware-software co-design process since it is used for functional validation and as a starting point for hardware-software partitioning and co-synthesis. The paper proposes the Java programming language as a specification language for hardware-software systems. Java has several characteristics that make it suitable for system specification. However static control and data flow analysis of Java programs is problematic because Java classes are dynamically linked. The paper provides a general solution to the problem of statically analyzing Java programs using a technique that pre-allocates most class instances and aggressively resolves memory aliasing using global analysis. The output of the analysis is a control data flow graph for the input specification. The results for sample designs show that the analysis can extract fine to coarse-grained concurrency for subsequent hardware-software partitioning and co-synthesis steps of the hardware-software co-design process to exploit.

Elements form a linear queue where head points to the front, next to the subsequent element, and tail to the back of the queue Figure 1: Type graph for CPM’s configurations as class diagram with constraints, where we assume disjoint finite sets of variable names (p1, . . . ,x1 . . . ), and reference names (r1, . . . ); let Meth be a finite set of method names, and Z be the set of integer numbers, B of Booleans; the cardinality of association edges is if not noted otherwise; the different regions highlight the different modules of the model each local processor advances as far as possible. Note that the walking of the control-flow graph and the scheduler are generic, i.e. represented by a set of GTS rules independent of the SCOOP program. We refer to [26] for the full formal model directly represented as GTS (that can be browsed and simulated with GROOVE). Modularity of CPM Configurations of CPM, i.e. global states of the system, can be partitioned into four main parts, which are also visible in Figure 1: (i) a representation of the underlying SCOOP program in the form of a control-flow graph; (ii) a system of concurrently running processors, each one possibly handling a request; these processors represent the system state; (iii) a waiting queue for each processor that stores pending requests; (iv) local memory state for each processor. The control flow component can be derived directly from the original CoreSCOOP program’s control flow graph (at a pre-compilation step) and its structure does not dynamically change, contrary to the state of the run-time environment (processors, queues, data). This partitioning is also mirrored by the GTS’s underlying rules that treat the walking of the control flow graph separately from the queue’s policies, the management of the memory, and global scheduling. The fixed simple interfaces (in form of the model components’ loose coupling due to the typed associations queue, handler, currentState, and requestType) between these modules allow us to plug in different behaviours for each module, e.g. different queueing semantics. Thus we can either adapt different existing SCOOP semantics (e.g. FIFO queues versus queues of queues [29]) or directly apply abstraction mechanisms in the context of verification (e.g. a counting abstraction of the queue’s content, or predicate abstraction for the data) by small modular changes to the underlying rules. Furthermore, the global abstract scheduling rules can be parameterised in this way, e.g. to include different kinds of garbage collection in the global scheduler or different rule prioritisations that keep the state space small, such as always preferring to terminate processors that are currently in a final state. i : ti l i it t i t , i j i t it t i l , . . . , . . . , , . . . ; l t t it t t , t t i t , l ; t i lit i ti i i t t t i ; t i t i i li t t i t l t l 38 Towards Practical Graph-Based Verification for an Object-Oriented Concurrency Model 4 Simulating CPM in GROOVE We realised CPM—our run-time model for CoreSCOOP—in GROOVE, an established tool for simulating and analysing GTS-based semantics. This section describes how we approached and achieved this task. First, we justify our choice of GROOVE, and then show (by example) how CPM configurations, rules, and rule applications are represented in the tool. Finally, we discuss the issue of CPM’s soundness. The GTS Tool GROOVE We chose GRaphs for Object-Oriented VErification (GROOVE) [14, 13] as our platform to implement and analyse the CPM models. Most existing GTS tools are in theory expressive enough to cover CPM. GROOVE however was already applied for the analysis of (non-concurrent) object-oriented programs in Java [24]. Furthermore, GROOVE contains a (finite-state) model checker that has proven sufficient for the analysis and verification of dynamic state systems [7, 18]. As reported in [31], GROOVE can typically handle systems with up to 4 million states, which should leave enough room for our first experiments. Finally, GROOVE convinced us with a gentle learning curve, its ease of adaption and extension to our needs, as well as its active development community. Representing CPM Configurations in GROOVE CPM configurations are represented in GROOVE quite straightforwardly, with control-flow, system state, waiting queue(s), and memory state (as in the type graph of Figure 1) all encoded in the same graph. 8 Towards Practical Graph-Based Verification for an Object-Oriented Concurrency Model A. Heusner, C.M. Poskitt, C. Corrodi, and B. Morandi 9 Data_Var name = v_3 value = 1 State Ref_Var name = r_1 Action assign var = v_1 State Data_Var name = v_1 value = 1

Automated program repair relying on static analysis complements test-driven repair, since it does not require failing tests to repair a bug, and it avoids test-overfitting by considering program properties. Due to the rich variety and complexity of program analyses, existing static program repair techniques are tied to specific analysers, and thus repair only narrow classes of defects. To develop a general-purpose static program repair framework that targets a wide range of properties and programming languages, we propose to integrate program repair with Datalog-based analysis. Datalog solvers are programmable fixed point engines which can be used to encode many program analysis problems in a modular fashion. The program under analysis is encoded as Datalog facts, while the fixed point equations of the program analysis are expressed as recursive Datalog rules. In this context, we view repairing the program as modifying the corresponding Datalog facts. This is accomplished by a novel technique, symbolic execution of Datalog, that evaluates Datalog queries over a symbolic database of facts, instead of a concrete set of facts. The result of symbolic query evaluation allows us to infer what changes to a given set of Datalog facts repair the program so that it meets the desired analysis goals. We developed a symbolic executor for Datalog called Symlog, on top of which we built a repair tool SymlogRepair. We show the versatility of our approach on several analysis problems --- repairing null pointer exceptions in Java programs, repairing data leaks in Python notebooks, and repairing four types of security vulnerabilities in Solidity smart contracts.

Calling context--the set of active methods on the stack--is critical for understanding the dynamic behavior of large programs. Dynamic program analysis tools, however, are almost exclusively context insensitive because of the prohibitive cost of representing calling contexts at run time. Deployable dynamic analyses, in particular, have been limited to reporting only static program locations. This paper presents Breadcrumbs, an efficient technique for recording and reporting dynamic calling contexts. It builds on an existing technique for computing a compact (one word) encoding of each calling context that client analyses can use in place of a program location. The key feature of our system is a search algorithm that can reconstruct a calling context from its encoding using only a static call graph and a small amount of dynamic information collected at cold (infrequently executed) callsites. Breadcrumbs requires no offline training or program modifications, and handles all language features, including dynamic class loading. We use Breadcrumbs to add context sensitivity to two dynamic analyses: a data-race detector and an analysis for diagnosing null pointer exceptions. On average, it adds 10% to 20% runtime overhead, depending on a tunable parameter that controls how much dynamic information is collected. Collecting less information lowers the overhead, but can result in a search space explosion. In some cases this causes reconstruction to fail, but in most cases Breadcrumbs >produces non-trivial calling contexts that have the potential to significantly improve both the precision of the analyses and the quality of the bug reports.

Static analyzers have become increasingly popular both as developer tools and as subjects of empirical studies. Whereas static analysis tools exist for disparate programming languages, the bulk of the empirical research has focused on the popular Java programming language. In this paper, we investigate to what extent some known results about using static analyzers for Java change when considering C#-another popular object-oriented language. To this end, we combine two replications of previous Java studies. First, we study which static analysis tools are most widely used among C# developers, and which warnings are more commonly reported by these tools on open-source C# projects. Second, we develop and empirically evaluate EagleRepair: a technique to automatically fix code in response to static analysis warnings; this is a replication of our previous work for Java [20]. Our replication indicates, among other things, that 1) static code analysis is fairly popular among C# developers too; 2) Re-Sharper is the most widely used static analyzer for C#; 3) several static analysis rules are commonly violated in both Java and C# projects; 4) automatically generating fixes to static code analysis warnings with good precision is feasible in C#. The EagleRepair tool developed for this research is available as open source.

Pointer analysis is a prerequisite for many program analyses, and the effectiveness of these analyses depends on the precision of the pointer information they receive. Two major axes of pointer analysis precision are flow-sensitivity and context-sensitivity, and while there has been significant recent progress regarding scalable context-sensitive pointer analysis, relatively little progress has been made in improving the scalability of flow-sensitive pointer analysis.This paper presents a new interprocedural, flow-sensitive pointer analysis algorithm that combines two ideas-semi-sparse analysis and a novel use of BDDs-that arise from a careful understanding of the unique challenges that face flow-sensitive pointer analysis. We evaluate our algorithm on 12 C benchmarks ranging from 11K to 474K lines of code. Our fastest algorithm is on average 197x faster and uses 4.6x less memory than the state of the art, and it can analyze programs that are an order of magnitude larger than the previous state of the art.

Calling context trees (CCTs) associate performance metrics with paths through a program's call graph, providing valuable information for program understanding and performance analysis. Although CCTs are typically much smaller than call trees, in real applications they might easily consist of tens of millions of distinct calling contexts: this sheer size makes them difficult to analyze and might hurt execution times due to poor access locality. For performance analysis, accurately collecting information about hot calling contexts may be more useful than constructing an entire CCT that includes millions of uninteresting paths. As we show for a variety of prominent Linux applications, the distribution of calling context frequencies is typically very skewed. In this paper we show how to exploit this property to reduce the CCT size considerably.We introduce a novel run-time data structure, called Hot Calling Context Tree (HCCT), that offers an additional intermediate point in the spectrum of data structures for representing interprocedural control flow. The HCCT is a subtree of the CCT that includes only hot nodes and their ancestors. We show how to compute the HCCT without storing the exact frequency of all calling contexts, by using fast and space-efficient algorithms for mining frequent items in data streams. With this approach, we can distinguish between hot and cold contexts on the fly, while obtaining very accurate frequency counts. We show both theoretically and experimentally that the HCCT achieves a similar precision as the CCT in a much smaller space, roughly proportional to the number of distinct hot contexts: this is typically several orders of magnitude smaller than the total number of calling contexts encountered during a program's execution. Our space-efficient approach can be effectively combined with previous context-sensitive profiling techniques, such as sampling and bursting.