Suresh Srinivas

Hardware atomicity for reliable software speculation

Speculative compiler optimizations are effective in improving both single-thread performance and reducing power consumption, but their implementation introduces significant complexity, which can limit their adoption, limit their optimization scope, and negatively impact the reliability of the compilers that implement them. To eliminate much of this complexity, as well as increase the effectiveness of these optimizations, we propose that microprocessors provide architecturally-visible hardware primitives for atomic execution. These primitives provide to the compiler the ability to optimize the programs hot path in isolation, allowing the use of non-speculative formulations of optimization passes to perform speculative optimizations. Atomic execution guarantees that if a speculation invariant does not hold, the speculative updates are discarded, the register state is restored, and control is transferred to a non-speculative version of the code, thereby relieving the compiler from the responsibility of generating compensation code. We demonstrate the benefit of hardware atomicity in the context of a Java virtual machine. We find incorporating the notion of atomic regions into an existing compiler intermediate representation to be natural, requiring roughly 3,000 lines of code (~3% of a JVMs optimizing compiler), most of which were for region formation. Its incorporation creates new opportunities for existing optimization passes, as well as greatly simplifying the implementation of additional optimizations (e.g., partial inlining, partial loop unrolling, and speculative lock elision). These optimizations reduce dynamic instruction count by 11% on average and result in a 10-15% average speedup, relative to a baseline compiler with a similar degree of inlining.

Practical experiences with Java software transactional memory

In this paper, we evaluate the emerging Transactional Memory (TM) area by developing a set of Java transactional memory workloads and studying their performance under a Java Software Transactional Memory (STM) system and comparing them to their lock based counterparts. We provide a detailed performance and memory consumption analysis of the overheads of software transactional memory and transactional workloads within a production quality open source Java Runtime system. Additionally, we detail the impact of the various performance optimizations in both workloads and the underlying runtime system to improving both single thread performance and scalability.

Hardware Atomicity: An Effective Abstraction for Reliable Software Speculation

Technology trends and shrinking power envelopes have forced microprocessor designers to focus on hardware techniques that efficiently improve single-thread performance without superlinear increases in power and silicon area. In this article, we identify hardware atomic execution - the execution of a region of code completely or not at all - as such a feature for simplifying existing and enabling new speculative compiler optimizations. Specifically, we propose that microprocessors expose atomic execution as a hardware primitive to the compiler. Doing so lets the compiler generate a speculative version of the code where infrequently executed code paths are removed.

Comparative performance analysis of mobile runtimes on Intel XScale® technology

Mobile Runtime Environments such as Java*2 Micro Edition (J2ME*) and Microsoft WinCE.NET* Compact Framework* are becoming standard managed application execution environments on memory constrained devices. A variety of implementations exists, and so too are a variety of systems they could run on, and finally a variety of workloads. It becomes important to understand how they compare.In this paper we describe comparative performance analysis of mobile runtimes on products with Intel XScale® micro-architecture. We were interested in a number of comparisons. These include CLDC vs. CDC workloads, Interpreters vs. JIT compilers, and J2ME vs. Native applications. In addition we compare runtimes when memory subsystem improves and MHz varies.We find that when comparing how mobile runtimes utilize the underlying micro-architecture, multiple implementations have similar stall analysis. We find that JIT (Just-In-Time) compilers are about 4-6 times faster than interpreters. For a class of applications we measured, J2ME apps were about two times slower than their C counterparts. We find that memory subsystem improvements have minor impact on interpreters but have much more impact on JIT compilers.