In Java, the object serialization model for data marshalling has various advantages over the MPI derived type mechanism. It provides much (though not all) of the flexibility of derived types, and is presumably simpler to use. Object serialization provides a natural way to deal with Java multidimensional arrays. Such arrays are likely to be common in scientific programming.
Our initial implementation of automatic object serialization in the context of MPI was impaired by performance of the serialization code in the current Java Development Kit. Buffers were serialized using standard technology from the JDK. The benchmark results from section 4 showed that this implementation of serialization introduces very large overheads relative to underlying communication speeds on fast networks and symmetric multiprocessors. Similar problems were reported in the context of RMI implementations in [11]. In the context of fast message-passing environments (not surprisingly) the issue is even more critical. Overall communication performance can easily be downgraded by an order of magnitude or more.
The standard Java serialization framework allows the programmer to provide optimized serialization and unserialization methods for particular classes, but in scientific programming we are often more concerned with the speed of operations on arrays, and especially arrays of primitive types. The standard Java framework for serialization does not provide a direct way to handle arrays, but in section 5 we customized the object streams themselves by suitably defining the replaceObject, resolveObject methods.
Our optimizations are somewhat dependent on the assumption that representation of primitive elements (their byte-order, for example) is the same in sender and receiver. This is commonly the case in MPI applications, where clusters are often homogeneous. In general an MPI-like package can always know in advance if sender and receiver have different layouts, and need only convert to an external representation if they do.
A different approach was taken by the authors of [17]. They opted for an extensive reimplemention of the JDK serialization code, to better support their optimized RMI. While their ideas can certainly benefit message-based APIs as well, they do not immediately support the ``zero-copy'' strategy we strive for here, whereby large arrays are removed from the serialization stream and dealt with separately--potentially by platform-specific software. In our case the platform-specific software was a native MPI binding, but in principle similar strategies could apply to other devices (such as a binding to VIA).
Given that the efficiency of object serialization can be improved dramatically--although probably it will always introduce a non-zero overhead--a reasonable question is whether a Java interface should dispense entirely with vestiges of MPI derived datatypes. We consider this case unproven. The MPI mechanism allows non-contiguous sections of a buffer to be sent directly. In practise implementations of MPI derived types, even in the C domain, have often had disappointing performance. But we note that VIA provides some low-level support for communicating non-contiguous buffers, and that recently there has been interest in producing Java bindings of VIA [5, 18]. So perhaps in the future it will become possible to support derived types quite efficiently in Java. We have emphasized the use of object serialization as a way of dealing with communication of Java multidimensional arrays. Assuming the Java model of multidimensional arrays (as arrays of arrays), we suspect serialization is the most natural way of communicating them. Note however that there is an active discussion (especially in Numerics Working Group of the Java Grande Forum) about how Fortran-like multidimensional rectangular arrays could best be supported into Java. Container class APIs have been proposed, and there are further proposals for compiler optimization by semantic inlining of accessor methods, or even true syntax extensions. The visibility or otherwise of the internal storage in the multidimensional container classes is subject to debate, but a reasonable guess is that multidimensional array sections will be represented as strided sections of some standard one-dimensional Java array. In this case the best choice for communicating array sections may come back to using MPI-like derived datatypes similar to MPI_TYPE_VECTOR.
In any case--whether or not a version of MPI derived data types survive in Java--the need to support object serialization in a message-passing API seems relatively clear.