Java/HPF Interface

When running on a parallel machine, the abstract unique thread of control of data-parallelism is actually implemented through multiple parallel processes running on the parallel processors, in the so-called SPMD mode. Each of these processes must be coupled with a Java VM running on the processor to achieve the functionality of a JNI. A straightforward design would involve one more Java VM as a front-end. However, such a design would either lead to unnecessary communications if the front-end is run on a remote machine, or to load unbalance if the front-end is run on one processor of the parallel machine. Thus no front-end has been implemented, but the Java programs that run in parallel have been designed in SPMD mode so as to offer to the external world the single thread semantics.

A true JNI would have the HPF codes launched by the Java VMs. More precisely, on each processor, the Java VMs would call the sequential code, compiled by an HPF compiler, as native procedures. Unfortunately, executing a parallel procedure is a less standardized process than in the sequential case: for instance, the set-up of the communication layer must complete before executing the actual user code, and there is no standard for all these parallel initializations. Hence, such a design cannot be compiler independent, and needs to know the internal of the compiler. To ensure portability across compilers and machines, we used the Java Invocation API, which allows to load a Java VM into a native application. Here, a Java VMs is launched on each processor from inside the HPF code, through HPF_LOCAL subroutines. After this point, the SPMD programs appear as native methods run inside Java threads. However, the SPMD programs are run as a whole. Thus the burden of synchronizing with the Domain Manager is on the HPF program. In practice, we had to mirror in HPF what should be the Java main program.