Miscellaneous language issues

Early versions of HPJava (see for example, [17]) adopted the position that a distributed array should be a kind of Java object. After working with this approach for some time, our position changed. In our current language definition a distributed array type is not an ordinary Java reference type. It is a new kind of reference type that does not extend Object. In practise a single distributed array is translated to several Java objects in the emitted code.

An early motivation for this change was to avoid introducing infinitely many different Java classes for the different distributed array types. However the change has other advantages. Now that a distributed array type no longer extends Object we are liberated from having to support various object-like behaviors, that would make efficient translation of operations on distributed arrays harder than it needs to be.

The HPJava translator only applies its transformations code in HPspmd classes. These are classes that implement a marker interface called HPspmd. Classes that do not implement this interface are not transformed and cannot use the special syntax extensions of HPJava.

Many of the special operations in HPJava rely on the knowledge of the currently active process group--the APG. This is a context value that will change during the course of the program as distributed control constructs limit control to different subsets of processors. In the current HPJava translator the value of the APG is passed as a hidden argument to methods and constructors of HPspmd classes (so it is handled something like the this reference in typical object-oriented languages).

The HPJava language has a set of rules that the translator enforces to help ensure a rational parallel program. These govern where in a program certain constructs can legally appear, and the allowed subscripts in distributed arrays.

The value of the current active process group is used to determine whether particular distributed control contructs and certain collective array operations are legal at particular points in a program. So long as these basic rules are respected, distributed control constructs can be nested freely, and generally speaking collective operations will operate properly within the restricted APGs in effect inside the constructs.

So far as subscripting is concerned, a characteristic rule is that distributed array element reference in:

$$\begin{minipage}[t]{\linewidth}\small\begin{tabbing} \verb$ ... ...{\tt ]}$\ \verb$ ...$ \\ \verb$ }$ \end{tabbing}\end{minipage}$$

is allowed if and only if

1. The expression $a$ is invariant in the overall construct.
2. All locations in $x \mbox{\tt [} l \mbox{\tt :} u \mbox{\tt :} s \mbox{\tt ]}$ are of elements $a \mbox{\tt .rng(} r \mbox{\tt )}$.

The syntax $x \mbox{\tt [} l \mbox{\tt :} u \mbox{\tt :} s \mbox{\tt ]}$ represents a subrange, and the inquiry $a \mbox{\tt .rng(} r \mbox{\tt )}$ returns the $r$th range of $a$. This rule is a statement about the overall construct as a whole, not about the array accesses in isolation. The rule applies to any access that appears textually inside the constructs, even if some conditional test in the body of the construct might prevent those accesses from actually being executed. This is important because it allows any associated run-time checking code to be lifted outside the local loops implied by an overall.