Safe futures for Java

Abstract

A future is a simple and elegant abstraction that allows concurrency to be expressed often through a relatively small rewrite of a sequential program. In the absence of side-effects, futures serve as benign annotations that mark potentially concurrent regions of code. Unfortunately, when computation relies heavily on mutation as is the case in Java, its meaning is less clear, and much of its intended simplicity lost.This paper explores the definition and implementation of safe futures for Java. One can think of safe futures as truly transparent annotations on method calls, which designate opportunities for concurrency. Serial programs can be made concurrent simply by replacing standard method calls with future invocations. Most significantly, even though some parts of the program are executed concurrently and may indeed operate on shared data, the semblance of serial execution is nonetheless preserved. Thus, program reasoning is simplified since data dependencies present in a sequential program are not violated in a version augmented with safe futures.Besides presenting a programming model and API for safe futures, we formalize the safety conditions that must be satisfied to ensure equivalence between a sequential Java program and its futureannotated counterpart. A detailed implementation study is also provided. Our implementation exploits techniques such as object versioning and task revocation to guarantee necessary safety conditions. We also present an extensive experimental evaluation of our implementation to quantify overheads and limitations. Our experiments indicate that for programs with modest mutation rates on shared data, applications can use futures to profitably exploit parallelism, without sacrificing safety.

Speculation with Little Wasting: Saving Cost in Software Speculation through Transparent Learning

“…Later techniques speculatively privatize shared arrays (to allow for false dependences) and combine the marking and checking phases (to guarantee progress) [2], [7]. Two programmable systems are developed in recent years: safe future in Java [21] and ordered transactions in X10 [20]. The first is designed for (typesafe) Java programs, whereas PPR supports unsafe languages with unconstrained control flows.…”

Lightweight checkpointing for concurrent ML

“…The ability to revert to a prior point within a concurrent execution is essential to transaction systems (Kung & Robinson 1981;Gray & Reuter 1993;Adya et al 1995); outside their role for database concurrency control, such approaches can improve parallel program performance by profitably exploiting speculative execution (Rinard 1999;Welc et al 2005). Harris et al (2005) proposes a transactional memory system for Haskell that introduces a retry primitive to allow a transactional execution to safely abort and be reexecuted, if desired resources are unavailable.…”

“…Stabilizers rely on unrolling thread dependencies of affected threads to ensure consistency instead of employing specific runtime mechanisms to reclaim resources. Safe futures (Welc et al 2005) bear some similarity to the speculative abstraction defined here as both provide a revocation mechanism based on tracking dynamic data and control-flow. However, safe futures do not easily compose with other Java concurrency primitives, and the criteria for revocation is automatically determined based on dependency violations, and is thus not under user control.…”

Adaptive Software Speculation for Enhancing the Cost-Efficiency of Behavior-Oriented Parallelization

“…Later techniques speculatively privatize shared arrays (to allow for false dependences) and combine the marking and checking phases (to guarantee progress) [1,2,4]. Two programmable systems are developed in recent years: safe future in Java [15] and ordered transactions in X10 [14]. The first is designed for (type-safe) Java programs, whereas PPR supports unsafe languages with unconstrained control flows.…”