Static import

Abstract: The talk provides an overview and demonstration of an Extended Static Checker for the Java programming language, a program checker that finds errors statically but has a much more accurate semantic model than existing static checkers like type checkers and data flow analysers. For example, ESC/Java uses an automatic theorem-prover and reasons about the semantics of assignments and tests in the same way that a program verifier does. But the checker is fully automatic, and feels to the programmer more like a type checker than like a program verifier. A more detailed account of ESC/Java is contained in a recent PLDI paper [1]. The checker described in the talk and in the PLDI paper is a research prototype on which work ceased several years ago, but Joe Kiniry and David Cok have recently produced a more up-to-date checker, ESC/Java 2 [2].

Abstract: The most serious impediment to writing substantial programs in the Java™ programming language is the lack of a gentricity mechanism for abstracting classes and methods with respect to type. During the past two years, several research groups have developed Java extensions that support various forms of genericity, but none has succeeded in accommodating general type parameterization (akin to Java arrays) while retaining compatibility with the existing. Java Virtual Machine. In this paper, we explain how to support general type parameterization---including both non-variant and covariant subtyping---on top of the existing Java Virtual Machine at the cost of a larger code footprint and the forwarding of some method calls involving parameterized classes and methods. Our language extension is forward and backward compatible with the Java 1.2 language and run-time environment: programs in the extended language will run on existing Java 1.2 virtual machines (relying only on the unparameterized Java core libraries) and all existing Java 1.2 programs have the same binary representation and semantics (behavior) in the extended language.

Abstract: Escape analysis is a static analysis that determines whether the lifetime of data may exceed its static scope.This paper first presents the design and correctness proof of an escape analysis for JavaTM. This analysis is interprocedural, context sensitive, and as flow-sensitive as the static single assignment form. So, assignments to object fields are analyzed in a flow-insensitive manner. Since Java is an imperative language, the effect of assignments must be precisely determined. This goal is achieved thanks to our technique using two interdependent analyses, one forward, one backward. We introduce a new method to prove the correctness of this analysis, using aliases as an intermediate step. We use integers to represent the escaping parts of values, which leads to a fast and precise analysis.Our implementation [Blanchet 1999], which applies to the whole Java language, is then presented. Escape analysis is applied to stack allocation and synchronization elimination. In our benchmarks, we stack allocate 13p to 95p of data, eliminate more than 20p of synchronizations on most programs (94p and 99p on two examples) and get up to 43p runtime decrease (21p on average). Our detailed experimental study on large programs shows that the improvement comes more from the decrease of the garbage collection and allocation times than from improvements on data locality, contrary to what happened for ML. This comes from the difference in the garbage collectors.

Abstract: Extensions and improvements of the programming language Java and its related execution environment (Java Virtual Machine, JVM) are the subject of a large number of research projects and proposals. There are projects, for instance, to add parameterized types to Java, to implement “Aspect-Oriented Programming”, to perform sophisticated static analysis, and to improve the run-time performance. Since Java classes are compiled into portable binary class files (called byte code), it is the most convenient and platform-independent way to implement these improvements not by writing a new compiler or changing the JVM, but by transforming the byte code. These transformations can either be performed after compile-time, or at load-time. Many programmers are doing this by implementing their own specialized byte code manipulation tools, which are, however, restricted in the range of their re-usability. To deal with the necessary class file transformations, we introduce an API that helps developers to conveniently implement their transformations.