The goal of points-to analysis for Java is to determine the set of objects pointed to by a reference variable or a reference object field. We present object sensitivity, a new form of context sensitivity for flow-insensitive points-to analysis for Java. The key idea of our approach is to analyze a method separately for each of the object names that represent run-time objects on which this method may be invoked. To ensure flexibility and practicality, we propose a parameterization framework that allows analysis designers to control the tradeoffs between cost and precision in the object-sensitive analysis.Side-effect analysis determines the memory locations that may be modified by the execution of a program statement. Def-use analysis identifies pairs of statements that set the value of a memory location and subsequently use that value. The information computed by such analyses has a wide variety of uses in compilers and software tools. This work proposes new versions of these analyses that are based on object-sensitive points-to analysis.We have implemented two instantiations of our parameterized object-sensitive points-to analysis. On a set of 23 Java programs, our experiments show that these analyses have comparable cost to a context-insensitive points-to analysis for Java which is based on Andersen's analysis for C. Our results also show that object sensitivity significantly improves the precision of side-effect analysis and call graph construction, compared to (1) context-insensitive analysis, and (2) context-sensitive points-to analysis that models context using the invoking call site. These experiments demonstrate that object-sensitive analyses can achieve substantial precision improvement, while at the same time remaining efficient and practical.A preliminary version of this article appeared in

wstractRelevant context inference (RCI) is a modular technique for flow-and context-sensitive data-flow analysis of statically typed object-oriented programming languages such as C++ and Java. RCI can be used to analyze complete programs as well as incomplete programs such as libraries; this approach does not require that the entire program be memoryresident during the analysis. RCIis presented in the context of points-to analysis for a realistic subset of Cts. The empirical evidence obtained from a prototype implementation argues the effectiveness of RCI.

Instrumenting code to collect profiling information can canse substantial execution overhead. This overhead makes instrumentation difficult to perform at runt/me, often preventing many known o]fiine feedback-directed optimizations from being used in online systems. This paper presents a general framework for performing instrumentation sampling to reduce the overhead of previously expensive instrumentation. The framework is simple and effective, using codeduplication and counter-based sampling to allow switching between instrumented and non-instrumented code.Our framework does not rely on any hardware or operating system support, yet provides a high frequency sample rate that is tunable, allowing the tradeoff between overhead and accuracy to be adjusted easily at runt/me. Experimental results are presented to validate that our technique can collect accurate profiles (93-98% overlap with a perfect profile) with low overhead (averaging ,-,6% total overhead with a naive implementation). A Jalapefio-specific optimization is also presented that reduces overhead further, resulting in an average total overhead of ~3%.

A?iasing occurs at some program point during execution when two or more names exist for the same location. We have isolated various programming language mechanisms which create aliases. We have classified the complexity of the fllas problem induced by each mechanism alone and in combination, as AfP-hard, complement tip-hard, or polynomial ('P). We present our problem classification, give an overview of our proof that finding interprocedural aliases in the presence of single level pointers is in 7, and present a represent tive proof for the NP-hard problems.

The goal of points-to analysis for Java is to determine the set of objects pointed to by a reference variable or a reference object field. This information has a wide variety of client applications in optimizing compilers and software engineering tools. In this paper we present a points-to analysis for Java based on Andersen's points-to analysis for C [5]. We implement the analysis by using a constraint-based approach which employs annotated inclusion constraints. Constraint annotations allow us to model precisely and efficiently the semantics of virtual calls and the flow of values through object fields. By solving systems of annotated inclusion constraints, we have been able to perform practical and precise points-to analysis for Java.We evaluate the performance of the analysis on a large set of Java programs. Our experiments show that the analysis runs in practical time and space. We also show that the points-to solution has significant impact on clients such as object read-write information, call graph construction, virtual call resolution, synchronization removal, and stackbased object allocation. Our results demonstrate that the analysis is a realistic candidate for a relatively precise, practical, general-purpose points-to analysis for Java.

No abstract

HISTORYTrying to look back over a ten-plus year period and to remember what influenced us at the time, is difficult and error prone. Thus, it is probable that these reflections are incomplete. Nevertheless, it is important to our field to trace the historical influences on new ideas.Our interest in aliasing was a natural continuation of work done at Rutgers in incremental dataflow analysis in the 1980's. 1 Much of this work focused on FORTRAN, but as time went on C became a very important language and its analysis was essential for compiler optimization and the development of software tools. The most significant difference between C and FORTRAN from a static analysis perspective was the ubiquity of pointer aliasing in C. Because of this ubiquity, having a viable solution to the Pointer May-alias problem was fundamental to any whole-program static analysis for general C programs. At the time, there was no work yielding precise program point specific aliases for entire C programs, so the problem was unsolved, challenging and necessary.We started, perhaps surprisingly, from computability theory. It was obvious that a precise computation would not be possible. However, we thought that it was important to understand which aspects of the problem could be solved precisely and which had to be approximated. By "could be solved" we meant there exists a polynomial algorithm. We felt this approach would give us an appreciation of a complex problem that could be the basis for its viable solution. This resulted in our paper Pointer-induced Aliasing: A Problem Classification [22] in which we demonstrated a precise polynomial algorithm for the aliases of single-level pointers.Our subsequent approach was to design an algorithm that was precise for single-level pointers, but approximate in the general case. In retrospect, this decision still seems appropriate. While the worst case time complexities of our algorithms were polynomial, the order of the polynomial was large enough that their scalability to very large programs was questionable. However, it was clear that this worst case behavior was not likely to be encountered in practice. Trying to perform any sort of average case analysis was not possible, because the concept of an average program was ill-defined. Thus, we decided it was important to validate our approach through empirical performance measurements. This approach, while not invented by us, has since our paper become a 1 http://prolangs.rutgers.edu 20 .$5.00. requirement for subsequent analyses. Our original theoretical slant also caused us to look into sources of imprecision in our algorithm, still an important theme on our program analysis work.Finally, we built upon a large body of work in dataflow analysis and abstract interpretation; some of the most influential were [2, 3, 6, 21, 30, 28, 38]. SINCE PLDI 1992In our group (PROLANGS). Our PLDI 1992 paper [23] explored the concepts of flow and context sensitivity, two important dimensions in static analysis algorithm design. Intuitively, flow sensitivity refers to w...

Small changes can have major and nonlocal effects in objectoriented languages, due to the use of subtyping and dynamic dispatch. This complicates life for maintenance programmers, who need to fix bugs or add enhancements to systems originally written by others. Change impact analysis provides feedback on the semantic impact of a set of program changes. This analysis can be used to determine the regression test drivers that are affected by a set of changes. Moreover, if a test fails, a subset of changes responsible for the failure can be identified, as well as a subset of changes that can be incorporated safely without affecting any test driver.