Support Vector Machines (SVMs) are used to discover method-specific compilation strategies in Testarossa, a commercial Just-in-Time (JiT) compiler employed in the IBM®J9 Java™ Virtual Machine. The learning process explores a large number of different compilation strategies to generate the data needed for training models. The trained machine-learned model is integrated with the compiler to predict a compilation plan that balances code quality and compilation effort on a per-method basis. The machine-learned plans outperform the original Testarossa for start-up performance, but not for throughput performance, for which Testarossa has been highly hand-tuned for many years.

The question addressed in this paper is what subset of code transformations should be attempted for a given method in a Just-in-Time compilation environment. The solution proposed is to use a Support Vector Machine (SVM) to learn a model based on method features and on the measured compilation and execution times of the methods. An extensive exploration phase collects a set of example compilations to be used by the SVM to train the model. This paper reports on a work in progress. So far, linear-SVM models, applied to benchmarks from the SPECjvm98 suite, have not outperformed the compilation plans engineered by the development team over many years. However the models almost match that performance for the javac benchmark.

Partial redundancy elimination aims to reduce the number of times an expression is computed more than once. The traditional Lazy Code Motion (LCM) algorithm formulated by Knoop, Ruthing and Steffen, through its reliance on unordered bit vectors, is severely limited in its ability to remove redundancy when precise exception semantics are required because bit vectors cannot express the order of exception checks. This paper describes our new PRE algorithm Exception Check Motion that uses the LCM algorithm to treat and optimize exception checks in a similar way to any other expression. Unlike earlier techniques that can remove only the compare instruction of a partially redundant exception check, our solution can eliminate both the compare and trap instructions without any run time code patching or expensive recovery operations. Since it is the trap instructions that restrict subsequent code motions, our technique gives downstream optimizations more flexibility to improve the performance of the resulting code once the partially redundant checks are eliminated. Our analysis has been implemented in the IBM® Testarossa (TR) just-in-time (JIT) compiler in the IBM Developer Kit for Java Release 5.0 as part of the J9 Virtual Machine. We measure performance improvements up to 7.6% and averaging 2.5% across 22 SPEC and DaCapo benchmarks on 4-way IBM pSeries (PowerPC) hardware.

In this paper, we introduce the IBMreg WebSpherereg real time product, which incorporates a virtual machine that is fully Javatrade compliant as well as compliant with the Real-Time Specification for Java (RTSJ). We describe IBM's real-time Java enhancements, particularly in the area of our Testarossa (TR) ahead-of-time (AOT) compiler, our TR just-in-time (JIT) compiler, and our Metronome (Bacon, et al., 2003) deterministic garbage collector (GC). The main focus of this paper is on the various techniques employed by the TR compilers to optimize and regulate the performance of code running in a real-time Java environment through a simple Java source code example. Through the example, we highlight the additional checks required to provide a conformant RTSJ implementation as well as the performance issues with ahead-of-time code generation and the overheads required to support Metronome. We show how these checks are implemented in a production JVM, and then report the cost of the real-time changes in practice for the example as well as the SPECjvm98 benchmark suite, SPECjbb2000, and SPECjbb2005

The emergence of standards for programming real-time systems in Java has encouraged many developers to consider its use for systems previously only built using C, Ada, or assembly language. However, the RTSJ standard in isolation leaves many important problems unaddressed, and suffers from some serious problems in usability and safety.

In this paper, we describe the techniques that have been implemented in the IBM TestaRossa (TR) just-in-time (JIT) compiler to safely perform aggressive code patching and collect accurate profiles in the context of a Java application employing multiple threads and dynamic class loading and unloading. Previous work in these areas either did not account for the synchronization cost of safety or dynamic class loading/unloading effects in a heavily multithreaded program or did not consider how different patching techniques may be required for different platforms where instruction cache coherence guarantees vary. We evaluate the space and time overhead to make our profiling framework correct, showing that privatizing the profiling variables to achieve correctness impacts execution time only minimally but it can grow the stack frames for profiled methods by less than 15% on average for the SPECjvm98 and SPECjbb2000 benchmarks. Since methods are profiled for only a brief time and the stack frames themselves are not large, we do not consider this growth to be prohibitive. The techniques reported in this paper are implemented in the 1.5.0 release of the IBM Developer Kit for Java targeting 12 different processor-operating system platforms.

We describe an automatic technique to remove repetitive synchronization in Java/spl trade/ programs by removing selected MONITORENTER/EXIT operations. Once these operations are removed, parts of a method that were not originally locked become protected by a lock. If it is unsafe to synchronize the code between the original locked regions, however, the code is not transformed. Scalability is also protected by not allowing a lock to be held for a significantly longer time than it would be held in the original program code. Our base algorithm improved the throughput of the industry-standard SPECjbb2000 benchmark by 2% to 5% for three different platforms. We also describe an extension to our algorithm to better handle virtual calls, which are prevalent in Java code, and this extension provides up to a further 5% improvement. Our computationally efficient algorithm was implemented and evaluated in a production Just-In-Time (JIT) compiler.

In anticipation of the emergence of multimedia applications as an important workload, microprocessor companies have augmented their instruction-set architectures with short vector extensions, thus adding basic vector hardware to state-of-the-art superscalar processors. Although a vector architecture may be a good match for multimedia applications, there is growing evidence that the control logic for increasingly complex superscalar processors is difficult to implement, Rather than combining a complex superscalar core with short wide vector hardware, we propose using a much simpler processor design that is similar to traditional vector computers with long vectors and simple control logic for instruction issue. Such a design would use the bulk of its transistors and die area for datapath and registers, and thus lessen the time required to design, implement, and verify control. In this paper we present data that quantifies this trading of control transistors for datapath and register transistors. We demonstrate that a 2-way, in-order vector processor with a vector length of 64 and a vector width of 8 requires no more die area, and possibly significantly less area, than a 4-way, out-of-order superscalar processor with short vector extensions. Furthermore, we show that the simple long vector processor is, on average, 2.7 times faster executing multimedia applications than the superscalar processor; and 1.6 times faster than one with short vector extensions. To explain the reasons for the higher performance, we analyze execution time in terms of dynamic operation count and cycles per operation (CPO). A vector processor executes fewer operations by using vector instructions to stripmine a loop. Moreover, a long vector processor achieves a lower CPO by effectively using parallelism at both the operation and the instruction levels. Thus by reducing both terms of the CPO equation, the simple long vector processor achieves greater performance.

Software pipelining is an aggressive scheduling technique that generates efficient code for loops and is particularly effective for VLIW architectures. Few software pipelining algorithms, however, are able to efficiently schedule loops that contain conditional branches. We have developed an algorithm we call All Paths Pipelining (APP) that addresses this shortcoming of software pipelining. APP is designed to achieve optimal or near-optimal performance for any run of iterations while providing efficient code for transitioning between runs. A run is the execution of consecutive iterations that all execute the same path through a loop. APP accomplishes this by using techniques from modulo scheduling and kernel recognition algorithms, the two main approaches for software pipelining loops. We have implemented the APP algorithm in our research compiler and have evaluated its performance by executing its generated code on a VLIW instruction-set simulator. For a processor with five heterogeneous functional units, APP is able to add another 1% to 23% increase in performance over basic software pipelining by effectively pipelining loops with conditional branches.