\chapter{Java for Parallel Programming}
\label{chap:grande}

In this chapter we give a general overview of the activities and
processes of the Java Grande Forum \cite{JAVAGRANDE}, a group looking at
general issues for large-scale computing in Java, and then outline
%various options for parallel programming in Java---possible ways to
%express parallelism, and ways to handle inter-process communication.
possible ways to handle inter-process communication. Finally we review
some of parallel computing environments and approaches for Java.

The Java Grande Forum is addressing many of the issues that arise in using
Java for High Performance Computing and Grande Applications.
It is a coalition of industrial and academic partners.
It has been organized with the goal of established consensus and
recommendations on possible enhancements to the Java language and Java 
standards for large-scale (``Grande'') applications. 
During the last few years it has held a series of ACM-supported
workshops and conferences that have helped stimulate research
on Java compilers and systems for Grande applications. 



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\section{The Java Grande Forum}
\section{Java for Scientific Computing}
\label{JAVAGRANDE}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The attractiveness of Java for scientific computing is being
encouraged by bodies like Java Grande \cite{JAVAGRANDE}.
The first meeting of the Java Grande Forum was held at ACM 1998 Workshop 
on Java for High-Performance Network Computing on
February 28 and March 1, 1998, in Palo Alto, California.  
The Java Grande Forum is motivated by the notion that Java has the 
potential to be a better language than previous
languages such as C and Fortran for developing large science and
``Grande'' applications, particularly on distributed and high-performance
computers. 
A Grande application is an application of a large scale nature,
potentially requiring any combination of computers, networks, I/O, and
memory. Examples may include, financial modeling, aircraft
simulation, climate and weather, satellite image processing and
earthquake prediction.

The major goal of the Java Grande Forum is to develop community
consensus and recommendations for either changes to Java or
establishment of standards for Grande libraries and services. 
The forum is open and operates with a mix of small working groups,
public dissemination and requests for comments on its recommendations.
Two major working groups were initially defined: the Numerics Working
Group and the Applications and Concurrency Working Group.

The goal of the Numerics Working Group is to assess the suitability of
Java for numerical computing, and to work towards community consensus
on actions to improve the language and its environment, in particular
for applications with significant requirements for floating-point
computation.  
In its initial assessment of Java, the working group has focussed on
five critical areas where improvements to the Java language are
needed: 
\begin{itemize}
	\item {floating-point arithmetic},
	\item {complex arithmetic},
	\item {multidimensional arrays},
	\item {lightweight classes}, and 
	\item {operator overloading.}
\end{itemize}
Lightweight classes and operator overloading provide key components to
proposed improvements for complex arithmetic and multidimensional
arrays. Information about the Numerics Working Group activities is
maintained at the {\it JavaNumerics} Web page at
http://math.nist.gov/javanumerics.

The second major working group is Applications and Concurrency group. The
activity of this group is particularly relevant to this dissertation.   
The goal of the group is to assess the suitability of Java for
parallel and distributed computing and so-called problem-solving
environments (applications), and to work towards community consensus
on actions that can be taken to improve the language and
environment. An important focus has been on the Java-specific
frameworks designed to support concurrent and high-performance
computing methodology.

Focusses of interest in the group include: 
\begin{itemize}
	\item {critical JDK issues},
	\item {benchmarking JVM performance},
	\item {seamless (desktop) access to high-performance
		computers (computing portals)}, and 
	\item {other parallel and distributed computing issues.}
\end{itemize}
Critical JDK issues are highest priority issues, mostly related to
performance of RMI and object serialization.
Other parallel and distributed computing issues include
the availability of MPI-like message passing facilities for
programming networks of computers. 

Some time after initial Java Grande working groups were defined,
a Message-Passing Working Group was formed in response to the
independent development by several groups of Java APIs for MPI-like and
PVM-like systems.
An immediate goal was to discuss a common API for MPI-like Java
libraries.  An initial draft for a common API specification was
distributed at Supercomputing '98 \cite{MPIPOSITION}.  Since then the
working group has met in San Francisco and Syracuse, and a Birds of a
Feather meeting was held at Supercomputing '99.  Minutes of meetings
were published on the {\em java-mpi} mailing list and are available at 
{\tt http://mailer.csit.fsu.edu/mail\-man/listinfo/java-mpi/}. To avoid
confusion with standards published by the original MPI Forum (which is
not presently convening) the nascent API is now called {\em MPJ}.
Work reported in this dissertation has been significant input to this
Message-Passing Working Group.

Information about the Java Grande Applications and Concurrency Working
Group activities can be found at {\tt http://www.javagrande.org}.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Communication in Parallel Programming}
\label{MPINJAVA}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Communication is essential to do parallel programming in
distributed systems.   
A distributed memory system consists of processors and their local
memories connected by an interconnection network. Since there is no
global memory, it is necessary to move data from one local memory to
another, ultimately by means of message-passing. This may done through
{\it send/receive} API calls which must be written into the
application program or by some higher-level software. 

In this section we discuss three different communication methods in
Java: socket, RMI (Remote Method Invocation), and message passing
libraries.  The first approach 
is to use the socket interface in the standard Java API. The second is
to work through Java's RMI.  Finally the third is to work through a
Java interface to the message-passing standard, MPI \cite{MPIFORUM}.
Message-passing remains one of the most effective and
widely used communication paradigms in parallel computing.
%We also compare two approaches to message-passing in Java,
%in the context of a ``scientific'' application.  The first approach is
%to use the socket interface in the standard Java API.  The second is
%to work through a Java interface to the message-passing standard, MPI
%\cite{MPIFORUM}.

%To minimize distracting details, our application will be elementary:
%Conway's Life automaton.

%In this section we discuss three approaches to message-passing in
%Java, in the context of a ``scientific'' application. The first
%approach is to use the socket interface in the standard Java API. The
%second is to work through Java's RMI.  Finally the third is to work
%through a Java interface to the message-passing standard, MPI
%\cite{MPIFORUM}. 
%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Java Sockets\label{sec:sockets}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The Java socket interface \texttt{java.net} provides two kinds of
socket classes, the streams-based  \texttt{Socket} class and the
datagrams-based \texttt{DatagramSocket} class.  A datagram is a
low-level networking interface and uses a protocol called
UDP (Unreliable Datagram Protocol) to tramsmit data.  
The \texttt{Socket} class allows programmers to connect to a specified
port and read and write data using the \texttt{InputStream} and
\texttt{OutputStream} of the \texttt{java.io} package.
The \texttt{DatagramSocket} class uses
\texttt{Datagram\-Packet} for data transmission 
and reception. Here the application creates a datagram packet
with the source and destination addresses and the relevant data and
uses \texttt{send()} and \texttt{receive()} to transmit data over the
network.  

The socket model is suitable for programming client-server applications.  
Typical scientific parallel programs do not fit directly into this model.  
Before a SPMD program can start two conditions must
obtain:  a pool of symmetric peer processes must have been created, and
each peer must be able to address a message to any other.

Carpenter et al \cite{Carpenter97} present a schematic outline of a
distributed Conway's Game of Life program using Java socket interface.
In this socket version example, they observed that 
\begin{itemize}
\item
Initialization of socket communication is a complex procedure and
clearly it should not be coded anew for each application program.
\item
In their Life example the messages
were contiguous byte vectors that could be transmitted efficiently
through the {\em read} and {\em write} methods of the Java socket API.
But in general the messages will have more complex types and the data may
not be contiguous in memory.  Using the typed primitives of the
standard API may then incur extra costs of copying and type-conversion.
\end{itemize}
For reasons such as these, even with the simplified Java socket API,
they concluded that direct socket programming will probably remain
unattractive to scientific parallel programmers, even with the
simplified Java socket API. 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Java RMI}
\label{RM}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Java Remote Method Invocation (RMI), which is an object-oriented version
of Remote Procedure Call (RPC), has been included with the Java
Development Kit release 1.1. 
RMI provides a simple and powerful Java-to-Java communication model
for invoking member functions on objects that exist in other Java
virtual machines, exactly as if it were local objects running in the
same virtual machines. 
%Java RMI is based on the Client-Server model. 
An overview of the RMI model is shown in figure~\ref{RMI.fig}.

\begin{figure}[t]
\centerline{\epsfig{figure=Figs/rmi.eps,width=5in}}
\caption{RMI Architecture. \label{RMI.fig}}
\end{figure}


The RMI architecture consists of three independent layers between the
application program and the Java virtual machine. Each layer is
independent and can be replaced by an alternate implementation.  The
three layers are the {\em Stub and Skeleton Layer}, the {\em Remote Reference
Layer}, and the {\em Transport Layer}. 
%The respective applications reside on both the client and server
%machines. The client and server communicate with the RMI system
%through a stub and skeleton respectively. These methods reside on top of the
%Remote Reference Layer and Transport Layer, allowing the RMI system to
%handle the interface. 
When a single request occurs, it travels down
through the layers on one computer and up through the layers at the
other end. 

The stub and skeleton layer is responsible for marshaling and
unmarshaling the data and transmitting and receiving them to/from the
Remote Reference Layer. The data are marshaled and unmarshaled using a
parameter-passing mechanism called {\it object serialization}.
Object serialization is an essential feature needed by Java's
RMI implementation. It provides a program the ability to read or write
a whole object to and from a raw byte stream. Object serialization
allows Java objects and primitives and to be encoded into a byte stream
suitable for streaming to some type of network or to a file-system.
In order to provide this functionality, an object must implement the
{\tt Serializable} interface. 


The Remote reference layer is responsible for carrying out the
invocation.
It can be behave differently depending on the parameters passed by the
calling program. For example, this layer can determine whether the
request is to call a single remote service or multiple remote programs
as in a multi-cast.

The Transport layer is responsible for setting up connections,
managing requests, monitoring them and listening for incoming calls.


High performance distributed computing can be done with Java RMI, but
this has a few drawbacks since RMI is designed for client-server
programming in Web based systems over slow networks.
In parallel programming fast RMI with low latency and high bandwidth
would be  required.
A better serialization would be needed, since Java's
object serialization often takes 25\%-50\% of the
time \cite{PHILIPPSEN99} needed for a remote invocation. 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Message Passing Libraries in Java}
\label{sec:MPJAVA}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The most popular message-passing libraries are PVM and MPI.
Several projects are under way to make message-passing
packages that support programs written in Java.
Current message-passing in Java can be classified into two
categories. The first category consists of Java based implementations that
use Java as wrapper for existing message-passing libraries
called through the Java native interface (JNI). 
The use of native methods achieves better performance and allows
programmers to reuse existing codes. However, it restricts jobs to run
only on systems where both Java and corresponding message-passing
library are supported.  
The second category of Java based implementations use only pure Java
libraries. Typically, in this case the underlying communication
libraries are Java's RMI or sockets.  The pure Java implementation
obtains a high degree of code portability among platforms but
may have  lower performance.  It is expected that the performance
problem will be reduced with just-in-time (JIT) compilation and other
compiler technologies.

In the next section we will discuss Java interfaces to two popular
message-passing standard, PVM and MPI.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{Parallel Virtual Machine (PVM) in Java}
\label{PVM}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
PVM, developed at Oak Ridge National Laboratory, is a message-passing
system that permits a heterogeneous collection of networked computing
systems to be used as a single large parallel machine. 
Thus large computational problems can be solved more cost
effectively by using the aggregate power and memory of many 
computers. 
PVM consists of two parts: a daemon process, {\it pvmd}, that
any user can install on a machine, and a user library that contains
routines for initiating processes on other machines. PVM provides a
rich set of dynamic resource management and process control
functions (eg., load balancing). It also allows the development of
fault-tolerant applications and has good
interoperability between heterogeneous hosts.
PVM supports programs written in C, C++, and Fortran. 

Currently there are two groups working on making PVM support programs
written in Java. 
%	\item {\bf Java-to-PVM interface} \\	
{\it JavaPVM} (or jPVM) \cite{JAVAPVM} is an interface written using the
Java native methods capability which allows Java applications to use
the Parallel Virtual Machine (PVM) software.
Since it is using native methods, it limits cross-platform
portability. 
%	\item {\bf Pure Java implementation of PVM} \\
{\it JPVM} \cite{JPVM} is a pure Java implementation of PVM. Therefore unlike
JavaPVM, it is better matched to Java programming styles and the
standardization of the JVM makes the JPVM code much simpler to
maintain across heterogeneous machine.
The performance is poor compared to JavaPVM.
The detail comparison of communication benchmark of native PVM,
JavaPVM, and JPVM is reported in \cite{YALAMA98}.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{Message-Passing Interface (MPI) in Java} 
\label{MPI}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
MPI \cite{MPIFORUM,USINGMPI} is a library of functions and macros that
can be used in C, FORTRAN, and C++ programs.  MPI is intended for use
in programs that exploit the existence of multiple processors by
message-passing.  MPI was developed by a group of researchers from
academia, industry, and government. As such, it is one of the first
standards for programming parallel processors, and it is the first
that is based on message-passing.
MPI provides a rich set of communication libraries,
application topologies and user defined data types. The first phase of
MPI (MPI 1) was focussed on developing a message-passing standard. The
second phase of MPI effort (MPI 2) is underway adding parallel I/O,
fault tolerance, language binding for C++ and additional
communications. 
Currently there are several known efforts towards the design of
MPI interfaces for Java.

\begin{itemize}
%\item {\bf Automatic generation of Java wrappers to MPI} \\
\item An approach comparable to the work described in this dissertation to
creating full Java MPI interfaces has been taken by University of
Westminster
\cite{MINCHEV97,GETOV98}. In their work Java wrappers were
automatically generated from the C MPI header using Java-to-C
interface generator (JCI). This eases the implementation work, but
does not lead to a fully object-oriented API.

%\item {\bf Pure Java implementations of MPI} \\
\item {\it MPIJ} \cite{MPIJ} is a pure Java-based subset of MPI developed at
Brigham Young University as part of the Distributed Object Group
Meta-computing Architecture (DOGMA) \cite{DOGMA} system.  MPIJ
implements a large subset of MPI functionality including
point-to-point commnunication, intra-communicator operations, groups,
user-defined reduction operations. MPIJ communications uses native
marshalling of primitive Java types. This technique allows MPIJ to
achieve communication speeds comparable to native MPI implementations.

\item {\it jmpi} \cite{JMPI98a,JMPI99} is a pure Java implementation of MPI built on
top of JPVM.  Due to the additional wrapper layer to JPVM routines,
its performance is expected to be poor compared to JavaPVM.

\item {\it JMPI} \cite{JMPICOM} is a commercial effort underway at MPI
Software Technology, Inc. to develop a message-passing framework and
parallel support environment for Java. It aims to build a pure Java
version of the MPI-2 standard specialized for commercial applications. 

%    \item {\bf Java Grande Forum's MPI-like API} \\
\item Finally, {\it MPJ} \cite{MPJ} is the Java Grande Forum's MPI-like
message-passing API proposed for both Java wrappers and a pure-Java
versions. The aim is to provide an implementation of MPJ that is 
maximally portable.

\end{itemize}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Parallel Computing Environments for Java}
\label{RELATED}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
In this section we review some of computing {\em environments} for Java that
are under development.
Currently several projects are under way that achieve increased
bandwidth, reduced latency, and better reliability within workstation
clusters using Java. 


\begin{figure}[bt]
\centerline{\epsfig{figure=Figs/JavaParty.eps,width=3.2in}}
\caption{The JavaParty system. \label{JavaParty.fig}}
\end{figure}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{JavaParty\label{sec:JavaParty}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The {\it JavaParty} \cite{JAVAPARTY} system of the University of
Karlsruhe, Germany, provides a mechanism for parallel cluster
programming in Java.
JavaParty adds remote objects to Java purely by
declaration avoiding disadvantages of explicit socket
communication and the programming overhead of RMI.
The \texttt{remote} keyword is used to identify which objects can be
called remotely.
JavaParty is location transparent, i.e., the programmer does not need
to map remote objects and remote threads to specific nodes of the
network; compiler and runtime system deal with locality and
communication optimization. 

JavaParty is implemented by a pre-processing phase added to the Java
compilers, EspressoGrinder \cite{ESPRESSO} and Pizza \cite{PIZZA}. 
As shown in the figure ~\ref{JavaParty.fig}, JavaParty code is
transformed into regular Java code plus RMI hooks. The resulting RMI
portions are then fed into RMI compiler (stub and skeleton
generator). 

For example, the following program fragment
\small
\begin{verbatim}
     remote class B {
         T x = I;           // instance variable
         T foo(V z) { P }   // method
     }
\end{verbatim}
\normalsize
may generate
\small
\begin{verbatim}
     interface B_intf extends RemoteIntf {...}
     class B_impl extends RemoteInstance implements B_intf {
         T x = I;           // instance variable
         public T foo(V z) throws RemoteException {  // method
             toRemote(P)
         }
     }
\end{verbatim}
\normalsize

JavaParty is important contribution to research on Java-based parallel
computing. Compared to approach in this dissertation, we expect to
suffer from some unavoidable overhead from the RMI mechanism, relative
to direct message-passing.  Also there is relatively little evidence
that the remote procedure call approach is actually convenient for SPMD
programming.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Javelin}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{figure}[bt]
\centerline{\epsfig{figure=Figs/Javelin.eps,width=3in}}
\caption{The Javelin Architecture. \label{Javelin.fig}}
\end{figure}

{\it Javelin} \cite{JAVELIN97} from the University of California, Santa
Barbara, is an Internet-based global computing
infrastructures that supports Java. In Javelin, there are three kinds
of participating entities: clients, hosts and brokers. A {\it client} is a
process seeking computing resources; a {\it host} is a process
offering computing resources; a {\it broker} is a process that
coordinates the supply and demand for computing resources. Figure
~\ref{Javelin.fig} illustrates the Javelin architecture. Clients register
with the broker their tasks to be run; hosts register with the broker
their intention to run tasks. The broker assigns tasks to hosts that
then run the tasks and send results back to the clients. 

The design is based on widely used components: Web browsers and the
portable Java. By pointing their browser to a known URL of a broker,
users automatically make their resources available to host parts of
parallel computations. This is achieved by downloading and executing
an applet that spawns a small daemon thread that waits and ``listens''
for tasks from the broker. This approach makes it easy for a host to
participate--all that is needed is a Java-capable web browser and the
URL of the broker.

It is good for very loosley-coupled parallel applications (``task
parallelism'') but it is less appropriate for the more tightly-coupled
SPMD programming made possible by our approach.
 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Efficient RMI and Object Serialization}
\label{EFFRMIOBJSERI}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
One of the goals of Java Grande Forum has been to investigate into methods
to optimize Java RMI and Object Serialization performance.
RMI implementations are built on top of TCP/IP, which was not designed
for High Performance Computing. 
Several research groups are pursuing research to improve efficiency of
Java RMI and object serialization implementation and its performance.

As part of the JavaParty project at the University of Karlsruhe,
Germany, described in section ~\ref{sec:JavaParty}, a more efficient
RMI and object serialization has been studied.
Philippsen et al \cite{PHILIPPSEN98} describe detailed analysis of
RMI and object serialization and it's performance problems. They also
suggest modifications to improve RMI and object serialization.
Based on these suggestions, they implemented more efficient version of
RMI and object serialization called KaRMI and UKA-serialization.
{\em KaRMI} \cite{NESTER99} improves the performance of RMI by clean
interfaces between layers and the separation of RMI's design from
transport level sockets. 
They also modify RMI to support non-TCP/IP communication networks.
KaRMI cannot handle code that uses socket factories or port numbers.
{\em UKA-serialization} \cite{PHILIPPSEN99} uses explicit
marshalling/unmarshalling routines instead of reflection and a minimal
encoding of type information to achieve better performance. 

%
Henri Bal's group of Vrije University, Netherlands, study an alternative
approach for implementing RMI, called {\em MantaRMI} \cite{MAASSEN99}, based
on native compilation for better optimization. 
Manta \cite{MANTA99} is compiler-based Java system and uses a native
compiler that generates executable code rather than byte code. 
The Manta system supports two different communication protocols.
Between Manta nodes, it can communicate through Manta's own a fast RMI
protocol using Manta's own serialization format. 
A Manta node can communicate with another JVM through a JDK-compliant
protocol using Sun's serialization format. 
With Manta, the serialization code is generated by the compiler which
make it possible to avoid the overhead of dynamic inspection of the
object structure. 


Krishnaswamy et al \cite{KRISHNASWAMY98} improve RMI performance by
adding object caching at the reference layer and using UDP (User
Datagram Protocol)-based reliable message delivery protocol.

Another implementation of RMI is provided by Thiruvathukal et al.  {em
Reflective RMI (RRMI)} \cite{RRMI98} adopted the reflection feature of
Java programming language to invoke remote methods.  RRMI makes it
possible of use RMI without stubs and skeletons. A remote object is
created dynamically at the run time by implementing its own class
loader on the server side.  It also supports both synchronous and
asynchronous remote method invocations.

Raje et al implement {\em ARMI} (Asynchronous RMI) \cite{RAJE} which adds
an asynchronous remote method to RMI. 
It achieves asynchronous communication by replacing the RMI
client-side stub, adding a thread mechanism. 

{\em NexusRMI} \cite{BREG98a} implements Java RMI on top of
NexusJava \cite{NEXUSJAVA}, which is a Java interface to the Nexus
communication system developed at Argonne National Laboratory. 
NexusRMI also has support for object serialization of all object types
except for exception objects.
%NexusRMI object serialization.....

%
At the University of California, Berkeley,
{\em NinjaRMI} \cite{WELSH} has been developed to support Ninja
project \cite{NINJA}. NinjaRMI has some features that are not found in
Sun's RMI including  multiple communication protocols.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Other Systems}
\label{sec:grande_related}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
A number of approaches have been proposed for parallel computing using
the Java language. 
In this section, we briefly descibe some of the ongoing projects. 

{\em Java/DSM} \cite{JAVADSM} is heterogeneous computing system which
implements a JVM on top of the Tread-Marks DSM (distributed shared
memory) system \cite{TreadMarks}.
In a DSM system, no explicit communication is necessary and that
eliminates the need for the programmer to write message-passing code.
Because of the portability feature of Java, the combination of Java and DSM
completely hides the hardware differences and the distributed nature
of the system from the programmer view, providing a better platform
for heterogeneous computing environments.

{\em JavaNow} \cite{JAVANOW99} is a pure Java based framework on shared
memory system that includes 
features found in Linda, Actors, and Message Passing
Interface (MPI). It creates a PVM like virtual parallel machine and
provides distributed associative shared memory.  JavaNow is currently
available as stand-alone software and must be used with a remote (or
secure) shell tool in order to run on a network of workstations.
 
{\em Titanium} \cite{TITANIUM98} is a Java based language and system for
high-performance parallel computing. It has additional features over
Java like immutable classes, multidimensional arrays, an explicitly
parallel SPMD model of computation with a global address space, and
a mechanism for programmer to control memory management. 
Immutable classes allow the compiler pass objects by value.
It does not provide any special support for distributed arrays, 
and the programming style is quite different to HPJava.
Because the Titanium compiler translates Titanium into C, users do not
have full access to the AWT or certain other Java libraries directly
from Titanium. 

{\em Spar} \cite{SPAR97} is a Java-based language for array-parallel
programming.
Spar has been designed as part of the {\em Automap} project,
in which a compiler and run-time system are being developed for
distributed memory systems.
Like our language it introduces multi-dimensional arrays,
array sections, and a parallel loop.  There are some similarities in
syntax, but semantically Spar is very different to HPJava.  Spar
expresses parallelism but not explicit data placement or
communication---in this sense it is a higher level language---closer to
HPF.

{\em javar} \cite{JAVAR97} is a simple Java restructuring compiler, 
written
in C, that can automatically transform a Java program into a 
form in which implicit parallelism is made explicit by means of
multi-threading. 

The {\em WebFlow} \cite{WEBFLOW} of Northeast Parallel Architectures 
Center,
Syracuse University, is a particular programming paradigm
implemented over a virtual Web accessible metacomputer, providing a
dataflow-programming model. A WebFlow application is given by a
computational visually edited by end-users, using Java
applets. Modules are written by module developers, people who have
only limited knowledge of the system on which the modules will
run. They need not concern themselves with issues such as allocating
and running the modules on various machines, creating connections
among the modules, sending and receiving data across these
connections, or running several modules concurrently on one
machine. The WebFlow system hides these management and coordination
functions from the developers, allowing them to concentrate on the
modules being developed.

{\it IceT} \cite{ICET97} is a collaborative, multi-user
environment. IceT provides mechanism by which resources can be made
available to the system for use by users who do not have log-on
privileges. The goals of this metacomputing-based approach
include better utilization of larger resource bases, as well as an
enhanced collaborative environment for high performance
computing. Among the challenges introduced by this idea are the
numerous security issues introduced by code-upload capabilities for
non-privileged uses.

In the next chapter we will review in detail our own HPJava parallel
programming environment. This will provide a setting for the main
original content of the dissertation.

%The major categories of Java Grande Related Work are shown in
%Table ~\ref{CATEGORIES}. We will discuss mpiJava, MPJ and HPJava in more
%detail in the next chapter. 
%%The following subsections explain these and other details.
%
%\begin{table}[tb]
%%\centerline{
%\begin{tabular}{| l || l | l | l | l |} \hline
%Category & Wrapper  & Pure Java & Extended Java & Web oriented\\ \hline 
%                 & mpiJava  & MPJ       & HPJava        & WebFlow \\
%System   & JavaMPI  & MPIJ      & Titanium      & Javelin \\
%             & JavaPVM 	& JPVM	    & Spar          & IceT \\
%             & Java/DSM & JavaNOW   & javar         &  \\ 
%             &          &           & JavaParty     &  \\ \hline
%
%\end{tabular}
%%}
%\caption{Categories of Java Grande Related Work\label{CATEGORIES}}
%\end{table}
%







