Fault-safe code motion for type-safe languages

  • Authors:

  • Brian R. Murphy;Vijay Menon;Florian T. Schneider;Tatiana Shpeisman;Ali-Reza Adl-Tabatabai

  • Affiliations:

  • Google, Beijing, China;Intel Labs, Santa Clara, CA, USA;ETH Zurich, Zurich, Switzerland;Intel Labs, Santa Clara, CA, USA;Intel Labs, Santa Clara, CA, USA

  • Venue:
  • Proceedings of the 6th annual IEEE/ACM international symposium on Code generation and optimization
  • Year:
  • 2008

Quantified Score

Hi-index 0.00

Visualization

Abstract

Compilers for Java and other type-safe languages have historically worked to overcome overheads and constraints imposed by runtime safety checks and precise exception semantics. We instead exploit these safety properties to perform code motion optimizations that are even more aggressive than those possible in unsafe languages such as C++. We present a novel framework for speculative motion of dangerous (potentially faulting) instructions in safe, object-oriented languages such as Java and C#. Unlike earlier work, our approach requires no hardware or operating system support. We leverage the properties already provided by a safe language to define fault safety, a more precise notion of safety that guarantees that a dangerous operation (e.g., a memory load) will not fault at a given program point. We illustrate how typical code motion optimizations are easily adapted to exploit our safety framework. First, we modify the standard SSAPRE partial redundancy elimination (PRE) algorithm to use fault safety, rather than the traditional down safety property. Our modified algorithm better exploits profile information by inserting of dangerous instructions on new paths when it is profitable and provably safe. Second, we extend an instruction trace scheduler to use fault safety to safely schedule load instructions across branches to better tolerate memory latency and to more compactly target instruction slots. We implemented these optimizations in StarJIT, a dynamic compiler, and show performance benefits of up to 10% on a set of standard Java benchmarks.