Search

As part of its type-safety regime, Java's semantics require precise exceptions at runtime when programs attempt out-of-bound array accesses. This paper describes a Java implementation that utilizes a multiphase approach to identifying safe array accesses. This approach reduces runtime overhead by spreading the out-of-bounds checking effort across multiple phases of compilation and execution: production of mobile code from source code, just-in-time (JIT) compilation in the virtual machine, application method invocations, and the execution of individual array accesses. The code producer uses multiple passes (including common subexpression elimination, load elimination, induction variable substitution, speculation of dynamically verified invariants, and inequality constraint analysis) to identify unnecessary bounds checks and prove their redundancy. During class-loading and JIT compilation, the virtual machine verifies the proofs, inserts code to dynamically validate speculated invariants, and generates code specialized under the assumption that the speculated invariants hold. During each runtime method invocation, the method parameters and other inputs are checked against the speculated invariants, and execution reverts to unoptimized code if the speculated invariants do not hold. The combined effect of the multiple phases is to shift the effort associated with bounds-checking array access to phases that are executed earlier and less frequently, thus, reducing runtime overhead. Experimental results show that this approach is able to eliminate more bounds checks than prior approaches with minimal overhead during JIT compilation. These results also show the contribution of each of the passes to the overall elimination. Furthermore, this approach increased the speed at which the benchmarks executed by up to 16%. Copyright © 2010 John Wiley & Sons, Ltd.

When the Java language is used in a large-scale real-time communications system, processing power presents a problem. The authors have been investigating an essential solution for this problem. This paper proposes a technique in which native code which has already been on-line compiled by a JIT compiler is dynamically reordered, based on profiling data obtained in the Java execution environment. The realization procedure is clearly described. The technique is to place segments of compiled code with high execution frequency close to each other as a group in memory. In addition, codes with low execution frequency are allocated to another area, so that the codes with high frequencies are more compactly placed. By this measure, the instruction cache hit rate of the processor is greatly increased and the processing performance in a large-scale program can be improved. The extent of performance improvement by applying the dynamic code reordering technique is evaluated, using applications with characteristics close to those of the real large-scale real-time communications program, and the effectiveness of the proposed method is demonstrated. © 2006 Wiley Periodicals, Inc. Electron Comm Jpn Pt 1, 89(11): 78–88, 2006; Published online in Wiley InterScience (www.interscience.wiley.com). DOI 10.1002/ecja.20185

This paper presents a strategy, called almost-whole-program compilation, for extending the benefits of whole-program optimization to large collections of Java components that are packaged as a group after the development phase. This strategy has been implemented in a framework that uses Java visibility and scoping rules to transform a collection of classes into a package that is amenable to whole-program optimizations, without precluding extensions to the optimized and compiled code. Thus, it enables the Java developer to balance performance against flexibility of the program after the development phase, without compromising the design process. The transformation is shown to incur only modest performance penalties, which are more than compensated for by the interprocedural optimizations it enables. The paper concludes with experimental results showing the benefits that can be achieved using this approach. Copyright c © 2005 John Wiley & Sons, Ltd.

It is a major challenge for a Java JIT compiler to perform single-precision floating-point operations efficiently for the x86 processors. In previous research, the double-precision mode is set as the default precision mode when methods are invoked. Sophisticated approaches then use heuristic approaches to optimization by considering the trade-offs between roundings and mode switches. However, this convention introduces redundant mode switches across method boundaries. Furthermore, methods that include both single- and double-precision operations cannot switch the mode, even if single-precision operations are dominant. We propose a new approach to these problems. We eliminate redundant mode switches by ignoring the default precision mode and calling a method in the same precision mode as the caller. For methods that include both single- and double-precision methods, we reduce the overhead of rounding by isolating code segments of a given method that should be executed in the single-precision mode. We implemented our approach in IBM's Just-in-Time compiler, and obtained experimental results demonstrating that, in SPECjvm98, it consistently shows the best performance in any configuration of benchmark programs, inline policies, and processor architectures compared with previous research approaches. Copyright © 2004 John Wiley & Sons, Ltd.

SUMMARY We report our experience from implementing and experimentally evaluating the performance of various register allocation schemes, focusing on the recently proposed linear scan register allocator .I n particular, we describe in detail our implementation of linear scan and report on its behavior both on register-rich and on register-poor computer architectures. We also extensively investigate how different options to the basic algorithm and to the compilation process as a whole affect compilation times and quality of the produced code. In a nutshell, our experience is that a well-tuned linear scan register allocator is a good choice on register-rich architectures. It performs competitively with graph coloring based allocation schemes and results in significantly lower compilation times. When compilation time is a concern, such as in just-in-time compilers, it can also be a viable option on register-poor architectures. Copyright c

The execution model for mobile, dynamically-linked, object–oriented programs has evolved from fast interpretation to a mix of interpreted and dynamically compiled execution. The primary motivation for dynamic compilation is that compiled code executes significantly faster than interpreted code. However, dynamic compilation, which is performed while the application is running, introduces execution delay. In this paper we present two dynamic compilation techniques that enable high performance execution while reducing the effect of this compilation overhead. These techniques can be classified as: 1) decreasing the amount of compilation performed ( Compilation), and 2) overlapping compilation with execution (Background Compilation). We first evaluate the effectiveness of lazy compilation. In lazy compilation, individual methods are compiled on demand upon their first invocation. This is in contrast toEager Compilation, in which all methods in a class are compiled when a new class is loaded. Our experimental results (obtained by executing the SpecJVM Java programs on the Jalape ˜ no JVM) show that, compared to eager compilation, lazy compilation results in % fewer methods being compiled and reductions in total time (compilation plus execution time) of %t o %. Next, we present profile-driven, background compilation, a technique that augments lazy compilation by using idle cycles in multiprocessor systems to overlap compilation with application execution. Profile information is used to prioritize methods as candidates for background compilation. Our results show that background compilation can deliver significant reductions in total time ( %t o %), compared to eager compilation.

The Java language incurs a runtime overhead for exception checks and object accesses, which are executed without an interior pointer in order to ensure safety. It also requires type inclusion test, dynamic class loading, and dynamic method calls in order to ensure flexibility. A ‘Just-In-Time’ (JIT) compiler generates native code from Java byte code at runtime. It must improve the runtime performance without compromising the safety and flexibility of the Java language. We designed and implemented effective optimizations for a JIT compiler, such as exception check elimination, common subexpression elimination, simple type inclusion test, method inlining, and devirtualization of dynamic method call. We evaluate the performance benefits of these optimizations based on various statistics collected using SPECjvm98, its candidates, and two JavaSoft applications with byte code sizes ranging from 23 000 to 280 000 bytes. Each optimization contributes to an improvement in the performance of the programs. Copyright © 2000 John Wiley & Sons, Ltd.

The term abstract machine is widely accepted to denote intermediate target languages and related architectures which serve as an intermediate stage in compiling programming languages. In this paper we explain how a considerable subset of Java is translated into Byte-Code for the Java Virtual Machine, an abstract machine used as a target for Java compilation. Using formal and precise notation we present the language concepts, the related byte-code instructions and the compilation schemes. Hitherto none of the existing literature on the JVM1,2 describes how compilation is done, but present the JVM in isolation. © 1998 John Wiley & Sons, Ltd.

This paper describes the design and implementation of CACAO, a just-in-time compiler for Java. The CACAO system translates Java byte code on demand into native code for the ALPHA processor. During this translation process the stack-oriented Java byte code is transformed into a register-oriented intermediate code. Local variables and stack locations are replaced by pseudo-registers eliminating the 32-bit restriction on address types. A fast register allocation algorithm is applied to map the pseudo-registers to machine registers. During code generation, field offsets are computed for proper alignment on 64-bit architectures. Even though the CACAO system has to incur loading and compilation time, it executes Java programs up to 85 times faster than the JDK interpreter, and up to seven times faster than the kaffe JIT compiler. It is slightly slower than equivalent C programs compiled at the highest optimization level. © 1997 John Wiley & Sons, Ltd.

The efficient execution of Java programs presents a challenge to hardware and software designers alike. The difficulty however lies with the Java bytecodes. Their model of a simplistic, platform-independent stack machine is well-suited for portability, though at the expense of execution speed. Various approaches are being proposed to increase the speed of Java bytecode programs, including: (1) on-the-fly compilation to native code (also known as JIT or "just-in-time" compilation); (2) traditional ("ahead-of-time") compilation of bytecodes to some higher-level intermediate form and then to native code; and (3) translation of bytecodes to a higher-level language and then use of an existing compiler to produce native code. Speedups on the order of 50 over standard bytecode interpretation have been claimed.All of these approaches rely upon bytecode analysis (of varying sophistication) to extract information about the program, which is then used to optimize the native code during the translation process. However, extracting information from a bytecode representation is expensive, and in general does not collect all the information originally available at the source-level.In this paper we propose an optimization approach based on bytecode annotations. The bytecodes are annotated during the original source code to bytecode translation, allowing both traditional interpretation by a JVM and aggressive optimization by an annotation-aware bytecode compiler. Annotations do not hinder portability nor compatibility, while preserving optimization information that is (1) expensive to recompute and (2) sometimes impossible to recompute. Preliminary results yield bytecode with C-like performance using JIT technology.

Our previous experience with an off-line Java optimizer [1] has shown that some traditional algorithms used in compilers are too slow for a JIT compiler. In this paper we propose and implement faster ways of performing analyses needed for our optimizations. For instance we have replaced reaching definitions with constant values and loop induction variables with loop-defined variables. As the result our JIT compiler, Briki, is very fast, so that its running time is negligible even when the data sets used with our benchmarks result in execution times of only a few seconds. The impact for the same benchmarks running on more realistic problem sizes would be even smaller. Currently the speedups resulting from applying our optimizations are between 10% and 20%, but when the JIT compiler will perform standard optimizations which are absent in the current version of the JIT compiler used by us, the speedups should be similar to the ones observed for Fortran programs—up to 50%.

We have developed a research compiler for Java class files. The compiler, which we call Briki, is designed to test new compilation techniques. We focus on optimizations which are only possible or much easier to perform on a high-level intermediate representation. We have designed such a representation, JavaIR, and have written a front-end which recovers high-level structure from the information from the class file. Some of the high-level optimizations can be performed by the Java compiler which produces the class file. There is however a set of machine-dependent optimizations which have to be customized for the specific architecture and so can only be performed when the machine code is generated from the bytecodes, e.g, in a Just-In-Time (JIT) compiler. We choose memory hierarchy optimizations as an example of machine-dependent techniques. We show that there is an intersection of the set of machine-dependent optimizations and the set of high-level optimizations. One such example is array remapping which requires multi-dimensional array references which are not present in the bytecodes and at the same time requires information about memory organization and the mapping of bytecodes to machine instructions. We develop a set of optimizations for accessing array elements and object fields and show their impact on set of benchmarks which we run on two machines with a JIT compiler. The execution times are reduced by as much as 50% and we argue that the improvement could be even higher with a more mature JIT technology.

Thread‐level speculation can be used to take advantage of multicore architectures for JavaScript in web applications. We extend previous studies with these main contributions; we implement thread‐level speculation in the state‐of‐the art just‐in‐time‐enabled JavaScript engine V8 and make the measurements in the Chromium web browser both from Google instead of using an interpreted JavaScript engine. We evaluate the thread‐level speculation and just‐in‐time compilation combination on 15 very popular web applications, 20 HTML5 demos from the JS1K competition, and 4 Google Maps use cases. The performance is evaluated on two, four, and eight cores. The results clearly show that it is possible to successfully combine thread‐level speculation and just‐in‐time compilation. This makes it possible to take advantage of multicore architectures for web applications while hiding the details of parallel programming from the programmer. Further, our results show an average speedup for the thread‐level speculation and just‐in‐time compilation combination by a factor of almost 3 on four cores and over 4 on eight cores, without changing any of the JavaScript source code.

In language systems that support separate compilation, we often observe that header files are internalized over and over again when the source files that depend on them are compiled. Making a compiler a long-lived server eliminates such redundant processing of header files, thus reducing the compilation time. The paper first describes compilation servers for C-family languages in general, and then a compilation server for our C-based object-oriented language in particular. The performance results of our server show that a compilation server can substantially shorten the compilation time.

Compilation time can be improved by precompiling interfaces so that the compiler can avoid processing unreferenced declarations. However, in C-based languages precompiling a header is difficult because a header can have several meanings depending on the context in which it is included. We present an ad hoc solution to this problem, and give the results of our precompilation strategy, which improved compile times by 25 to 65 per cent over compilation without precompiled headers.