Language Binding

Special issues for Java binding:

• Some options allowed for derived data types in the C and Fortran binding are deleted in the Java binding. The Java VM does not provide any concept of a global linear address space. Passing physical addresses to data type definitions is not allowed, and use of the MPI_TYPE_STRUCT datatype constructor is restricted in a way that makes it impossible to send mixed primitive types in a single message. In an initial implementation it will not be possible to directly send a general Java object in a message. We assume that Java programmers who want to achieve this goal will explicitly serialize their objects before transmitting them. Later we hope to treat MPI.JAVA_OBJECT as a new MPI primitive type, with serialization handled automatically in the wrapper code.
• Message buffers in C or Fortran can be multidimensional arrays, so it may seem natural to allow Java message buffers to be multidimensional arrays. But a Java multi-dimensional array does not necessarily map to a contiguous chunk of memory (it is implemented as a vector of separately allocated arrays), so there is no obvious way to support this facility in a ``wrapper'' interface. Hence Java message buffers are always one dimensional arrays with primitive element type. To allow a little extra flexibility, an offset parameter is associated with any buffer argument. This defines the position of the first actual buffer element in the Java array.
• Unlike the C and Fortran interfaces, the Java interfaces to MPI calls will not return explicit error codes. The Java exception mechanism will be used to report errors. This mechanism is very widely used by Java libraries. It is inconvenient to use up the single return value of a Java function with an error code (Java doesn't allow function arguments to be passed by reference, so returning multiple values tends to be more awkward than in normal languages). A few functions in the MPI interface return multiple values, even after the error code is eliminated. In these cases the Java binding returns a single object of some artificial class introduced to support the function concerned.
• To permit a straightforward wrapper implementation it seems to be necessary to impose some non-interference rules for concurrent read and write operations on arrays. When an array is passed to an MPI member such as a send or receive operation, the wrapper code will extract a pointer to the contents of the array using a JNI Get<PrimitiveType>ArrayElements routine. If the garbage collector does not support ``pinning'' (temporarily disabling run-time relocation of data for specific arrays), the pointer returned by this Get function may be to a temporary copy of the elements. The copy will be written back to the true Java array when a subsequent call to Release<PrimitiveType>ArrayElements is made. If two operations involving the same array are active concurrently, this copy back may result in failure to save modifications made by one or more of the concurrent calls.

  For safety, the rule suggested is that when several MPI send or receive (etc) operations are active concurrently, if any one of those operations writes to a particular array, none of the other operations must read or write any portion of that array.

  Operations may occur concurrently through explicit use of threads, or through use of non-blocking communication operations. So far as use of non-blocking communication operations is concerned, the restriction could be relaxed at the price of having the wrapper always explicitly copy buffers using MPI_PACK and MPI_UNPACK. Of course this is an undesirable overhead. A final decision on whether this overhead is acceptable will be defered until the implementation is more complete.