Supporting Exception Handling for Futures in Java

Lingli Zhang, Chandra Krinz, and Priya Nagpurkar

The International Conference on the Principles and Practice on Programming in Java (PPPJ) September, 2007, Monte de Caparica/Lisbon, Portugal



A future is a simple and elegant construct that programmers can use to identify potentially asynchronous computation and to introduce parallelism into serial programs. In its recent 5.0 release, Java provides an interface-based implementation of futures that enables users to encapsulate potentially asynchronous computation and to define their own execution engines for futures. In prior work, we have proposed an alternative model, called directive-based lazy futures (DBLFutures), to support futures in Java, that simplifies Java programmer effort and improves performance and scalability of future-based applications. In the DBLFuture model, programmers use a new directive, @future, to specify potentially concurrent computations within a serial program. DBLFutures enable programmers to focus on the logic and correctness of a program in the serial version first, and then to introduce parallelism gradually and intuitively. Moreover, DBLFutures provide greater flexibility to the Java virtual machine for efficient future support.

In this paper, we investigate the exception handling aspect of futures in Java. In Java 5.0 futures, exceptions of future execution are propagated to the point in the program at which future values are queried (used). We show that this exception handling model is not appropriate or desirable for DBLFutures. Instead, we propose an as-if-serial exception handling mechanism for DBLFutures in which the system delivers exceptions at the same point as they would be delivered if the program was executed sequentially. Our approach, we believe, provides programmers with intuitive exception handling behavior and control. We present the design and implementation of our approach within the DBLFuture framework in the Jikes Research Virtual Machine. Our results show that our implementation introduces negligible overhead forapplications without exceptions, and guarantees serial semantics of exception handling for applications that throw exceptions.