Aaron W. Keen

JR: Flexible distributed programming in an extended Java

Java provides a clean object-oriented programming model and allows for inherently system-independent programs. Unfortunately, Java has a limited concurrency model, providing only threads and remote method invocation (RMI).The JR programming language extends Java to provide a rich concurrency model, based on that of SR. JR provides dynamic remote virtual machine creation, dynamic remote object creation, remote method invocation, asynchronous communication, rendezvous, and dynamic process creation. JRs concurrency model stems from the addition of operations (a generalization of procedures) and JR supports the redefinition of operations through inheritance. JR programs are written in an extended Java and then translated into standard Java programs. The JR run-time support system is also written in standard Java.This paper describes the JR programming language and its implementation. Some initial measurements of the performance of the implementation are also included.

Exception Handling during Asynchronous Method Invocation

Exception handling mechanisms provided by sequential programming languages rely upon the call stack for the propagation of exceptions. Unfortunately, this is inadequate for handling exceptions thrown from asynchronously invoked methods. For instance, the invoking method may no longer be executing when the asynchronously invoked method throws an exception. We address this problem by requiring the specification of handlers for exceptions thrown from asynchronously invoked methods. Our solution also supports handling exceptions thrown after an early reply from a method and handling exceptions after forwarding the responsibility to reply. The JR programming language supports the exception handling model discussed in this paper.

JR: flexible distributed programming in an extended Java

Java provides a clean object-oriented programming model and allows for inherently system-independent programs. Unfortunately, Java has a limited concurrency model, providing only threads and remote method invocation (RMI). The JR programming language extends Java to provide a rich concurrency model. JR provides dynamic remote virtual machine creation, dynamic remote object creation, remote method invocation, asynchronous communication, rendezvous, and dynamic process creation. JR programs are written in an extended Java and then translated into standard Java programs. The JR run-time support system is also written in standard Java. This paper describes the JR programming language and its implementation. Some initial measurements of the performance of the implementation are also included.

Fairness in shared invocation servicing

Invocation servicing is an important aspect of many concurrent programming languages. Some invocation handling mechanisms allow for multiway servicing by multiple processes. This paper addresses fairness with respect to choosing which invocation to service and fairness with respect to choosing which process to perform the servicing. It examines how these fairness issues have been resolved in the SR concurrent programming language. This paper presents a new approach that eliminates several key restrictions. The new approach has been implemented in JR, an extended Java that includes SR-like synchronization mechanisms. This paper discusses design and implementation issues and tradeoffs.

An exception handling mechanism for the concurrent invocation statement

Several concurrent programming languages and systems – e.g., MPI, .NET, and SR – provide mechanisms to facilitate communication between one process and a group of others. One such mechanism is SRs concurrent invocation statement (co statement). It specifies a group of operation invocations and normally terminates when all of its invocations have completed. To make the co statement more flexible, it can specify code in the invoker to execute as each invocation completes or to terminate the entire co statement before all of its invocations have completed. We have added an SR-like co statement to JR. Unlike SR, JR provides exception handling mechanisms, which are integrated with Javas exception handling mechanism. However, JR needs additional mechanisms to deal with sources of asynchrony. The co statement introduces additional such sources of asynchrony for the invocations it initiates. This paper describes the design and implementation of an exception handling mechanism for JRs co statement.

Generic operations and capabilities in the JR concurrent programming language

Abstract The JR concurrent programming language extends Java with additional concurrency mechanisms, which are built upon JRs operations and capabilities. JR operations generalize methods in how they can be invoked and serviced. JR capabilities act as reference to operations. Recent changes to the Java language and implementation, especially generics, necessitated corresponding changes to the JR language and implementation. This paper describes the new JR language features (known as JR2) of generic operations and generic capabilities. These new features posed some interesting implementation challenges. The paper describes our initial implementation (JR21) of generic operations and capabilities, which works in many, but not all, cases. It then describes the approach our improved implementation (JR24) uses to fully implement generic operations and capabilities. The paper also describes the benchmarks used to assess the compilation and execution time performances of JR21 and JR24. The JR24 implementation reduces compilation times, mainly due to reducing the number of files generated during JR program translation, without noticeably impacting execution times.

A comparison of concurrent programming and cooperative multithreading

This paper presents a comparison of the cooperative multithreading model with the general concurrent programming model. It focuses on the execution time performance of a range of standard concurrent programming applications. The overall results are mixed. In some cases, programs written in the cooperative multithreading model outperform those written in the general concurrent programming model. The contributions of this paper are twofold. First, it presents a thorough analysis of the performances of applications in the different models, i.e. to explain the criteria that determine when a program in one model will outperform an equivalent program in the other. Second, it examines the tradeoffs in writing programs in the different programming styles. In some cases, better performance comes at the cost of more complicated code. Copyright

Transformations for early reply and forward message passing mechanisms

Message passing notations (language, package, etc.) typically include some form of asynchronous or synchronous invocation. In a synchronous invocation, the invoker waits for the invocations servicer to pass back results. Some message passing notations also include early reply or deferred reply (including forwarding), which alters how and when the servicer passes back its results; this additional flexibility is useful in realistic applications. It is well known how to transform a synchronous invocation into only asynchronous invocations. This paper extends such transformations to early reply and forward. This paper also describes the use of these transformations within the implementations of programming notations. Using the transformation simplifies the implementation without significantly affecting run‐time costs. Copyright

User accessible reply capabilities in invoking and servicing operations

Many message passing languages and packages include some form of synchronous invocation. In a synchronous invocation, the invoker waits for the invocations servicer to pass back results. A synchronous invocation can be viewed as a pair of asynchronous invocations: one—initiating the computation—with parameter values from the invoker to the servicer and the other—once the requested computation has completed—with the ‘go‐ahead’ and return value from the servicer to the invoker. The target of the latter invocation is known as the reply operation, and a reference to it is known as a reply capability. This paper addresses the issues of making such reply capabilities directly accessible to user code. It presents the design and prototype implementation of a new version of the JR concurrent programming language, called xJR, in which the reply capability can be explicit. This paper gives xJR examples, including realistic ones, to highlight the additional flexibility the new features offer (such as a non‐lexical reply). These additional features do not impact the run‐time performance of existing JR features and can even lead to more efficient code in some programming scenarios. Our experience with the prototype implementation indicates that an actual implementation would be fruitful and would preserve the prototypes performance advantages. Copyright

Toward a definition of and linguistic support for partial quiescence

The global quiescence of a distributed computation (or distributed termination detection) is an important problem. Some concurrent programming languages and systems provide global quiescence detection as a built-in feature so that programmers do not need to write special synchronization code to detect quiescence. This paper introduces partial quiescence (PQ), which generalizes quiescence detection to a specified part of a distributed computation. Partial quiescence is useful, for example, when two independent concurrent computations that both rely on global quiescence need to be combined into a single program. The paper describes how we have designed and implemented a PQ mechanism within an experimental version of the JR concurrent programming language. Our early results are promising qualitatively and quantitatively.