Multiarray Types and HPspmd Classes

A multiarray type is not treated as a class type. If we said, ``multiarrays have a class'', it would probably commit us to either extending the definition of class in the Java base language, or creating genuine Java classes for each type of HPJava array that might be needed. Since class is so fundamental in Java, extending its definition seems impractical. On the other hand, creating Java classes for each multiarray type has its own semantic problems. Presumably the associated class types would have to embed all the information for multiarray types we have described for HPJava. Since $T$ can be any Java type, there is an infinite number of multiarray types. Thus, whenever needed at compiler-time, the associated classes would have to be created on demand by the translator. Now, we can ask ourselves a question, ``Does the translator have to generate distributed class files whenever we need them?'' If the answer is ``yes'', how are we supposed to manage all the generated class files? Figure 4.1 illustrates that multiarray types have a quite complex, multiple-inheritance-like lattice. This kind of type lattice can be recreated in Java by using interface types. But then, when we generate a new array class, we have to make sure all the interfaces it implements directly and indirectly are also generated.

Figure 4.1: Part of the lattice of types for multiarrays of int.

This seems too complicated. So we decided that a multiarray type is not a class type. The fact that a multiarray is not a member of any Java class or primitive type means that a multiarray cannot be an element of an ordinary Java array, nor can a multiarray reference be stored in a standard library class like Vector, which expects an Object. In practise, this is not such a big restriction as it sounds. We do allow multiarrays to be fields of classes. So, the programmer can make wrapper classes for specific types of multiarray. For example, suppose we need a ``stack'' of two-dimensional multiarrays of floating point numbers. We can make a wrapper class, Level, as follows:

$$\begin{minipage}[t]{\linewidth}\small\begin{verbatim} class Level... ...; l++) stack [l] = new Level(new int [[x, y]]) ;\end{verbatim}\end{minipage}$$

Thus, it is minor inconvenience that multiarrays are not treated as normal objects, not a fundamental limitation. The HPJava translator must tell parallel code from sequential code. It introduces a special interface, hpjava.lang.HPspmd, which must be implemented by any class that uses the parallel syntax. An HPspmd class is a class that implements the hpjava.lang.HPspmd interface. Any other class is a non-HPspmd class. Also, an interface that extends the hpjava.lang.HPspmd interface is called an HPspmd interface, and any other interface is a non-HPspmd interface. The parallel syntax of HPJava can only be used in methods and constructors declared in HPspmd classes and interfaces. To further discourage invocation of HPspmd code from non-HPspmd code, the HPJava translator imposes the following limitations:

1. If a class or interface inherits a method with the same signature from more than one of its superclasses and superinterfaces, either all declarations of the method must be in HPspmd classes and interfaces, or all declarations of the method must be in non-HPspmd classes and interfaces. So an inherited method can always be unambiguously classified as an HPspmd method or a non-HPspmd method.
2. An HPspmd class or interface may not override a non-HPspmd method.

The details of HPspmd class restrictions can be found in [9]. 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).