\chapter{Java for Scientific Parallel Programming}

\section{Introduction}

The initial growth of interest in Java was driven
largely by its role in bringing a new generation of interactive
pages to the World Wide Web. Undoubtedly various features of the
language---compactness, byte-code portability, security, and so
on---make it particularly attractive as an implementation language for
applets embedded in Web pages and servlets embedded in servers. But it
was always clear that the ambitions of 
the Java development team go well beyond enhancing the functionality
of HTML documents. Many of their concerns, such as portability,
execution in a heterogeneous network environment, and efficiency, mirror
development in High Performance Computing world over a number of
years \cite{FOX97,HPFFORUM,PVM,MPIFORUM}. 

With Java positioned to become a standard programming language on the
Internet, and scientific parallel processing edging towards
network-based computation, it is natural to ask how these two
technologies will interact. How suitable is Java for scientific
computing, and do lessons from research in parallel computing have
implications for the development of Java?

Popular acclaim aside, there are some reasons to think that Java may
be a good language for scientific and parallel programming.
\begin{itemize}
	\item {Java is a descendant of C++. C and C++ are used
	increasingly in scientific programming. In recent years numerous
	variations on the theme of C++ for parallel computing have
	appeared. See, for example \cite{DONGARRA,FINK,GRIMSHAW,WILSON} }	

	\item {Java omits various features of C and C++ that are
	considered ``difficult''---notably, pointers. Poor compiler analysis
	has often been blamed on these features. The inference is that
	Java, like Fortran, may be a suitable source language for highly
	optimizing compilers.} 

	\item {Java comes with builtin multithreading. On a shared memory
	platform independent threads may be scheduled on different
	processors by a suitable runtime. Even without physical shared
	memory, mulitithreading can 
	be very convenient in explicit message-passing styles of parallel
	programming.}

\end{itemize}


The outline of this lecture is as follows.
Section ~\ref{JAVAGRANDE} provides a general overview of the Java
Grande Forum, its activities, and the process.
Java Grande Forum is addressing many of the issues that arise in using
Java for High Performance Computing and Grande Applications.
Section ~\ref{ISSUES} and ~\ref{MPJAVA} of this lecture outline
various options for 
parallel programming in Java--possible ways to express parallelism,
and ways to handle inter--process communication.
Finally in Section ~\ref{RELATED}, we look at related work of Java
Grande.  

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Java Grande Forum}
\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 Java '98 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 large scale nature,
potentially requiring any combination of computers, networks, I/O, and
memory. For examples, 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 and
public dissemination and request for comments on its recommendations.
Currently, two working groups are exist: Numeric Working Group and
Concurrency/Applications Working Group.

The goal of the Numeric Working Group is to assess the suitability of
Java for numerical computing, and to work towards community consensus
on actions which can be taken to improve the language and its
environment for applications with significant requirements for
floating-point computation. In its initial assessment of Java, the
working group has focused 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}
	\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 Numeric Working Group activities is
maintained at the JavaNumeric web page at
http://math.nist.gov/javanumerics.

The goal of the Concurrency/Applications Working 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 which can be taken to improve
the language and environment. The focus has been on the Java-specific
frameworks designed to support concurrent and high-performance
computing methodology. The working group is organized as follows:
\begin{itemize}
	\item {\bf critical JDK issues} \\
		highest priority issues, mostly related to performance of RMI
		and Object Serialization
	\item {\bf benchmarking JVM performance}
	\item {\bf seamless(desktop) access to high-performance
		computers(computing portals)}
	\item {\bf other parallel and distributed computing issues} \\
		the availability of MPI-like message passing facilities for
		programming networks of computers		
\end{itemize}
Information about the Java Grande Concurrency and Applications Working
Group activities can be found at http://www.javagrande.org and
following the direct link to Working Groups.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Java for Scientific Parallel Programming Issues}
\label{ISSUES}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Approaches to Parallelism in Java}
\label{PJAVA}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Java already supports concurrency through the thread mechanism and
monitor synchronization built into the language. In this lecture
we are interested in truly {\it parallel} computation, involving
multiple CPUs. Such parallelism could be introduced into Java in a
number of ways.

It could be achieved through automatic parallelization of sequential
code, but it is unclear why this easier for Java than for other
languages. Alternatively, the Java virtual machine for a shared memory
multiprocessor can schedule the threads of a multi-threaded Java
program on different processors. Some success with these approaches in
reported in \cite{BIK}. For computation on a network(or distributed
memory computer) realistic options include language extensions or
directives akin to HPF, or provision of libraries---class
libraries---to support task parallelism or data parallelism.

A popular approach in C++ has been to defer language extensions and
concentrate on class library support for parallel programming. The
similarities between the two languages suggest this may be a fruitful
avenue in Java too. The success of this analogy is by no means
automatic, however. Features such as {\it templates} and user-defined
{\it operator overloading} make the C++ language inherently more
customizable than Java. In C++ library-defined types can be used on an
identical footing to primitive types---{\it inline} methods mean they
can be almost as efficient as primitive types. Less importantly, but
conveniently, new control constructs can often be simulated in C or
C++ through use of macros. On grounds, presumably, of simplicity and
transparency many of these features have been omitted from Java.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Communication in Java}
\label{COMMJAVA}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The standard Java API provides a simplified interface to Internet
sockets and RMI, a Java version of Remote Procedure Call (RPC). 

The socket interface hides much of the ugly detail involved in
socket-programming at the traditional C/Unix level. The {\it java.net}
interfaces provides less flexibility than using the system calls
directly. On the other hand, Java's built-in support for threads adds
some flexibility in scheduling communications that is missing from
raw C. 
Traditionally socket programming has not been a popular paradigm in
the parallel processing world, where more successful schemes include
 
\begin{itemize}
	\item {Message-passing through language-level support or
	higher-level library interfaces \cite{MPIFORUM}. }

	\item {Data parallelism, which we take to mean the style of
	programming in which parallelism is achieved through operations on
	distributed arrays, with synchronization typically limited to bulk
	synchronization occurring naturally through collective array
	operations.} 

	\item {Communication through shared memory or shared objects,
	involving some more or less intricate mechanism for inter-process
	synchronization.} 
\end{itemize}


Communication through remote objects(i.e RMI) is undoubtedly a natural and
important paradigm in Java, especially for access to remote services.
However, RMI is too restrictive and its overhead for dealing with network
problems is too verbose for the cluster setting. It suffers from a
significant startup time and marshaling/unmarshaling of data is more
costly than in the socket method.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Message Passing with Java}
\label{MPJAVA}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
A distributed memory system consists of processors and their local
memories connected by interconnection network. Since there is no
global memory, it is necessary to move data from one local memory to
another by means of message-passing. This is typically done through
{\it send/receive} API calls which must be written into the
application program.  
Message-passing remains one of the most effective and widely used
communication paradigms in parallel computing.
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{SOCKETS}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The Unix socket model is most 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. Bootstrapping this situation typically involves one host
starting remote invocations of the program (for example by using {\it
rsh} or a specialized daemon). All the peers will create listening
sockets, and all the port numbers must be broadcast somehow, then
socket connections will be made.

Even with the simplified Java socket API, direct socket programming
will remain unattractive to scientific parallel programming.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\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 an 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. 
As most distributed processing is conceived, RMI is based on the
Client-Server model. An overview of the Java 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 Stub and Skeleton Layer, the Remote Reference
Layer, and the 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
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 request, monitoring them and listening for incoming calls.


High performance distributed computing can be done with Java RMI, but
this has a few weakness since RMI is designed for client-server
programming in Web based systems over slow networks.
In parallel programming, fast RMI with low latency, high bandwidth,
and better reliability are required.
A better serialization is also needed for a fast RMI, 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{MPJAVA}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The most popular message-passing libraries are PVM and MPI.
Several projects are under way to make message-passing
packages to support programs written in Java.
Current message-passing in Java can be classified into two
categories. First category consists of Java based implementations that
use Java as wrapper for existing message-passing libraries that are
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 system where both Java and corresponding message-passing
library are supported.  

The second category of Java based implementations use only pure
Java libraries.  
Typically, this case the underlying communication libraries are Java's
RMI or socket. 
The pure Java implementation obtains high degree of code portability
among platforms but relatively lower performance.  The performance
problem is expected to be overcome with just-in-time (JIT) compilation
and other compiler technologies.

In the next section we will discuss Java interface 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 machine. 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 with host or task failure 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. 


\begin{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
	\item {\bf Java-to-PVM interface} \\	
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
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 method, it limits cross-platform
portability. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
	\item {\bf Pure Java implementation of PVM} \\
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
JPVM \cite{JPVM} is a pure Java implementation of PVM. Therefore unlike
JavaPVM, it is better matched 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}.

	\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\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 topology and user defined data types. The first phase of
MPI (MPI 1) was focused 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 early
MPI interfaces for Java.

\begin{itemize}
	\item {\bf Automatic generation of Java wrappers to MPI} \\
An approach comparable to our work 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} \\
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.
Since it is implemented in only Java, portability....

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

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 targets to build a pure Java version of MPI-2
standard specialized for commercial applications. 
\end{itemize}




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Related Work of Java Grande}
\label{RELATED}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Currently several projects are under way that achieve increased
bandwidth, reduced latency, and better reliability within workstation
clusters using Java. In this section we briefly discuss some works
related to Java Grande. 


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

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{JavaParty}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The 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 as a pre-processing phase into 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 \& skeleton
generator). 

%The main JavaParty design and implemetation are as follows.
%\begin{itemize} 
%\item {Remote Object creation: }
%Objects can be created on remote hosts by calling a regular class
%constructor at the destination. The library routine \texttt{\_new()}
%calls the constructor object on target JVM and return a remote
%reference to the new objects. 
%
The runtime system consists of a central component, called {\it
RuntimeManager}. In addition, each host runs a {\it LocalJP} that is
registered at the manager. A host and its LocalJP can be added
dynamically to the system. The manager knows all LocalJPs and knows the
location of all class objects, i.e., for each class that is loaded the
manager knows which host implements the static part. This information
is replicated in the LocalJPs to reduce manager load. Neither manager
nor LocalJPs need to know the location of individual remote
objects. LocalJPs are needed to call constructors in class objects and
to implement either side of migration.

JavaParty also supports object migration.
For actually migrating an object, the runtime system offers two
options. An object can move to the position of the caller or it can be
moved to the location of different remote object. A migration is
possible if no method is executing on the object, no other migration is
in progress, and the object does not have its \texttt{resident} flag
set. Then the object's internal state is serialized into a byte array
which is sent to the runtime system on the target host. The receiving
runtime system unpacks the byte array and returns an RMI stub
reference to the runtime system of the original host. Upon receipt,
the original host completes the migration.


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

Javelin \cite{JAVELIN97} of the University of California, Santa
Barbara, is internet-based global computing
infrastructures that support 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 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. 


One of the most important goals of Javelin is {\it simplicity},
i.e., to enable everyone connected to the Internet or an intranet to
{\it easily} participate in Javelin. To this end, the design is based
on widely used components: Web browsers and the portable Java. By
simply 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. The simplicity of 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.

\begin{figure}[bt]
\centerline{\epsfig{figure=Figs/Javelin2.eps,width=3.5in}}
\caption{Steps involved in the remote execution of an applet.  
\label{Javelin2.fig}}
\end{figure}
 
In Figure ~\ref{Javelin2.fig} shows the steps involved in the remote
execution of an applet. These steps are:

\begin{enumerate}
\item The client uploads the applet and an embedding HTML page on an
HTTP server. Clients running their own HTTP server may skip the first
step. 
\item The client registers the corresponding URL with a broker.
\item The host registers with the broker its intention to execute
tasks, and retrieves the URL of a task.
\item  The host downloads the HTML page from the HTTP server, and
executes its embedded applet.
\item The host stores the result at the server site. If communication
between cooperating hosts is required, messages are stored at, and
retrieved from, the server site.
\item The client retrieves the result.
\end{enumerate}

The server is an HTTP server that performs two separate
functions. First, it stores clients' applets and serves them to hosts;
secondly, it provides point-to-point communication among hosts by
serving as smart router. 

Tasks are represented as applets embedded in HTML pages. This design
decision implies certain limitations due to Java applet security:
E.g., all communication must be routed through the broker and every
file access involves network communication. Therefore, in general,
coarse-grained applications with a high computation to communication
ratio are well suited to Javelin.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Efficient RMI and Object Serialization}
\label{EFFRMIOS}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
One of the goals of Java Grande Forum is 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 \cite{JAVAPARTY} project at the University of
Karlsruhe, Germany, a more efficient RMI and object serialization have
been studied. 
Philippsen et al \cite{PHILIPPSEN98} describe detailed analysis of
RMI and object serialization and it's performance problem. They also
suggest modifications to improve RMI and object serialization.
Based on these suggestions, they implement more efficient version of
RMI and object serialization called KaRMI and UKA-serialization.
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 factory or port numbers.
UKA-serialization \cite{PHILIPPSEN99} uses explicit
marshaling/unmarshaling 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 Manta RMI \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. 
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. 
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.
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 a asynchronous remote method
invocations.

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

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

%
At the group of the University of California, Berkeley,
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 parallel and distributed computing in Java}
\label{OTHERS}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Most Java based parallel systems can be classified into four classes.
\begin{itemize} 
\item {\bf Use Java as wrapper for existing frameworks.} \\
Java/DSM is heterogeneous computing system which implements a JVM on
top of Tread-Marks distributed shared memory(DSM) system.
In 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.

\item {\bf Use pure Java libraries} \\
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.
 
\item {\bf Extend Java language with new keywords} \\
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.
Because Titanium compiler translates Titanium into C, users do not
have full access to the AWT and certain other Java libraries directly
from Titanium. 

Spar \cite{SPAR97} is a programming language for semi-automatic
parallel programming, in particular for the programming of array-based
applications, supporting multidimensional and sparse arrays. 
Spar has been designed as part of the Automap project,
in which a compiler and run-time system are being developed for
distributed memory systems.

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. 

\item {\bf Web oriented Java based frameworks} \\
WebFlow \cite{WEBFLOW} of Northeast Parallel Architectures Center,
Syracuse University, is a particular programming paradigm
implemented over a virtual Web accessible metacomputer and given by a
dataflow-programming model. 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 not need 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.


IceT \cite{ICET97} is an inherently 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 attractive 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.


\end{itemize}

The major categories of Java Grande Related Work are shown in
figure~\ref{CATEGORIES}. We will discuss mpiJava, MPJ and HPJava more in
detail next chapter. 


\begin{figure}[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{figure}


