Download CIS6930: Java Remote Method Invocation

Java for High Performance Computing
Java RMI and RMI-Based Approaches
for HPC
http://www.hpjava.org/courses/arl
Instructor: Bryan Carpenter
Pervasive Technology Labs
Indiana University
[email protected]
1
Remote Method Invocation

Java RMI is a mechanism that allows a Java program running on
one computer to apply a method to an object living on a different
computer.
– RMI is an implementation of the of the Distributed Object programming
model—similar to CORBA, but simpler and specialized to the Java
language.

The syntax of the remote method invocation looks like an
ordinary Java method invocation.
– The remote method call can be passed arguments computed in the context
of the local machine. It can return arbitrary values computed in the
context of the remote machine. The RMI runtime system transparently
communicates all data required.
– In some ways Java RMI is more general than CORBA—it can exploit
Java features like object serialization and dynamic class loading to
provide more complete object-oriented semantics.
[email protected]
2
Distributed Object Picture

Code running in the local machine holds a remote reference to
an object obj on a remote machine:
obj
res = obj.meth(arg) ;
ResType meth(ArgType arg) {
. . . Any code …
return new ResImpl(. . .) ;
}
Local Machine
Remote Machine
[email protected]
3
Java RMI References

Java RMI, Troy Bryan Downing, IDG books, 1998.

“Getting Started Using RMI”, and other documents, at:
http://java.sun.com/products/jdk/rmi/

Java RMI Lectures in “Applications of IT” course, run
at Florida State University, 2001:
http://aspen.ucs.indiana.edu/it1spring01/
[email protected]
4
A Simple Use of RMI
[email protected]
5
The Remote Interface


In RMI, a common remote interface is the minimum amount
of information that must be shared in advance between
“client” and “server” machines. It defines a high-level
“protocol” through which the machines will communicate.
A remote interface is a normal Java interface, which must
extent the marker interface java.rmi.Remote.
– Corollaries: because the visible parts of a remote object are defined
through a Java interface, constructors, static methods and non-constant
fields are not remotely accessible (because Java interfaces can’t
contain such things).

All methods in a remote interface must be declared to throw
the java.rmi.RemoteException exception.
[email protected]
6
A Simple Example

A file MessageWriter.java contains the interface definition:
import java.rmi.* ;
public interface MessageWriter extends Remote {
void writeMessage(String s) throws RemoteException ;
}

This interface defines a single remote method,
writeMessage().
[email protected]
7
java.rmi.Remote


The interface java.rmi.Remote is a marker interface.
It declares no methods or fields; however, extending it tells
the RMI system to treat the interface concerned as a remote
interface.
– In particular we will see that the rmic compiler generates extra code
for classes that implement remote interfaces. This code allows their
methods to be called remotely.
[email protected]
8
java.rmi.RemoteException




Requiring all remote methods be declared to throw
RemoteException was a philosophical choice by the
designers of RMI.
RMI makes remote invocations look syntactically like local
invocation. In practice, though, it cannot defend from
problems unique to distributed computing—unexpected
failure of the network or remote machine.
Forcing the programmer to handle remote exceptions helps to
encourage thinking about how these partial failures should be
dealt with.
See the influential essay: “A Note on Distributed Computing”
by Waldo et al, republished in The Jini Specification:
http://java.sun.com/docs/books/jini
[email protected]
9
The Remote Object




A remote object is an instance of a class that implements a
remote interface.
Most often this class also extends the library class
java.rmi.server.UnicastRemoteObject. This class includes
a constructor that exports the object to the RMI system when
it is created, thus making the object visible to the outside
world.
Usually you will not have to deal with this class explicitly—
your remote object classes just have to extend it.
One fairly common convention is to name the class of the
remote object after the name of the remote interface it
implements, but append “Impl” to the end.
[email protected]
10
A Remote Object Implementation Class

The file MessageWriterImpl.java contains the class declaration:
import java.rmi.* ;
import java.rmi.server.* ;
public class MessageWriterImpl extends UnicastRemoteObject
implements MessageWriter {
public MessageWriterImpl() throws RemoteException {
}
public void writeMessage(String s) throws RemoteException {
System.out.println(s) ;
}
}
[email protected]
11
Compiling the Remote Object Class

To compile classes that implement Remote, you must use the
rmic compiler. The reasons will be discussed later. For
example:
sirah$ rmic MessageWriterImpl
[email protected]
12
Client and Server Programs



We have completed the Java files for the remote object class
itself, but we still need the actual client and server programs
that use this class.
In general there are some pieces of administrivia one has to
deal with—publishing class files and installing security
managers.
We initially make the simplifying assumption that both client
and server have copies of all class files for MessageWriter
(e.g., they may share access through shared NFS directories).
– Then “publishing class files” is not an issue, and we also don’t need a
security manager, because all code is “local”, and therefore trusted.
[email protected]
13
A Server Program

We assume the file HelloServer.java contains the class
declaration:
import java.rmi.* ;
public class HelloServer {
public static void main(String [] args) throws Exception {
MessageWriter server = new MessageWriterImpl() ;
Naming.rebind(“messageservice”, server) ;
}
}
[email protected]
14
Remarks

This program does two things:
– It creates a remote object with local name server.
– It publishes a remote reference to that object with external
name “MessageWriter”.

The call to Naming.rebind() places a reference to server in
an RMI registry running on the local host (i.e., the host where
the HelloServer program is run).

Client programs can obtain a reference to the remote object by
looking it up in this registry.
[email protected]
15
A Client Program

We assume the file HelloClient.java contains the class
declaration:
import java.rmi.* ;
public class HelloClient {
public static void main(String [] args) throws Exception {
MessageWriter server =
(MessageWriter) Naming.lookup(
“rmi://sirah.csit.fsu.edu/messageservice”) ;
server.writeMessage(“Hello, other world”) ;
}
}
[email protected]
16
Remarks



Again the program does two things:
– It looks up a reference to a remote object with external
name “MessageWriter”, and stores the returned reference
with local name server.
– Finally (!), it invokes the remote method, writeMessage(),
on server.
The call to Naming.lookup() searches in a remote RMI
registry. Its argument is a URL, with protocol tag “rmi”.
This example assumes the remote object lives on the host
“sirah”, and has been registered in the default RMI registry
(which happens to listen on port 1099) on that machine.
[email protected]
17
Compiling and Running the Example

Compile HelloServer and HelloClient on their respective
hosts, e.g.:
sirah$ javac HelloServer
merlot$ javac HelloClient

Either ensure client and server share the current directory, or
copy all files with names of the form MessageWriter * .class
to the client’s current directory.
[email protected]
18
Running HelloClient/HelloServer
[email protected]
19
The Mechanics of Remote Method
Invocation
[email protected]
20
Is RMI a Language Extension?


Invocation of a method on a remote object reproduces the
“look and feel” of local invocation very well.
But the internal mechanics of remote invocation are much
more complex than local invocation:
– Arguments—which may be objects of arbitrary complexity—are
somehow collected together into messages suitable for shipping across
the Internet.
– Results (or exceptions) are similarly shipped back.

Perhaps surprisingly, RMI involves no modification to the
Java language, compiler, or virtual machine.
– The illusion of remote invocation is achieved by clever libraries, plus
one relatively simple “post-processor” tool (rmic).
[email protected]
21
Exchanging Remote References


A powerful feature of distributed object models like RMI is
that references to other remote objects can be passed as
arguments to, and returned as results from, remote methods.
Starting with one remote object reference (presumably
obtained from an RMI registry) a client can, for example,
obtain references to additional remote objects—returned by
methods on the first one.
[email protected]
22
Example: a Printer Registry

Suppose we are on a LAN and we need to get a Java driver
for one of several available printers:
public interface Printer extends Remote {
void print(String document) throws RemoteException ;
}
public interface PrinterHub extends Remote {
Printer getPrinter(int dpi, boolean isColor)
throws RemoteException ;
}



A client might initially obtain a PrinterHub reference from
the RMI registry. The remote object contains some table of
printers on the network.
An individual Printer interface is returned to the client,
according to specifications given in getPrinter().
Jini takes an approach similar to this.
[email protected]
23
Remote References have Interface Type

This is a powerful feature, but there is one interesting
restriction:
– If a particular argument or result of a remote method itself
implements Remote, the type appearing in the method
declaration must be a remote interface.
– The declared type of an RMI argument or result cannot be
a remote implementation class.
– At the “receiving end” this reference cannot be cast it to
the implementation class of the remote object. A
ClassCastException will occur if you try.
[email protected]
24
Stubs

What this tells us is that “remote references” are not literally
Java references to objects in other virtual machines.

In fact they are Java references to local objects that happen to
implement the same remote interfaces as the remote objects
concerned.

The local Java object referenced is an instance of a stub class.
[email protected]
25
Some Important Parts of RMI

Stubs.
– Each remote object class has an associated stub class, which
implements the same remote interfaces. An instance of the stub class
is needed on each client. Client-side remote invocations are “actually”
local invocations on the stub class.

Serialization.
– Arguments and results have to be “marshaled”—converted to a
representation that can be sent over the Net. In general this is a highly
non-trivial transformation for Java objects. Serialization is also used
for distributing stubs.

The Server-side “Run-time System”.
– This is responsible for listening for invocation requests on suitable IP
ports, and dispatching them to the proper, locally resident, remote
object.
[email protected]
26
Architecture
Internet
Client
Call stub method
locally
Client
Code
Call remote object
method locally
Send marshaled
arguments
Stub
Return value
or throw exception
Server
Send marshaled
result or
exception
RMI
“Run-time”
System
[email protected]
Remote
Object
Return value
or throw exception
27
The Role of rmic




The only “compiler” technology peculiar to RMI is the rmic
stub generator.
The input to rmic is a remote implementation class, compiled
in the normal way with javac (for example).
The stub generator outputs a new class that implements the
same remote interfaces as the input class.
The methods of the new class contain code to send arguments
to, and receive results from, a remote object, whose Internet
address is stored in the stub instance.
[email protected]
28
Example Operation of rmic

An earlier example of a remote implementation class:
public class MessageWriterImpl extends UnicastRemoteObject
implements MessageWriter {
...
public void writeMessage(String s) throws RemoteException {
...
}
}

We issue the command:
rmic –keep MessageWriterImpl
– The flag –keep causes the intermediate Java source to be retained.
[email protected]
29
The Generated Stub Class
public final class MessageWriterImpl_Stub
extends java.rmi.server.RemoteStub
implements MessageWriter, java.rmi.Remote {
...
public MessageWriterImpl_Stub(java.rmi.server.RemoteRef ref) {
super(ref);
}
public void writeMessage(java.lang.String $param_String_1)
throws java.rmi.RemoteException {
try {
ref.invoke(this, $method_writeMessage_0,
new java.lang.Object[] {$param_String_1},
4572190098528430103L);
} ...
}
}
[email protected]
30
Remarks on the Stub Class

The stub class includes an inherited field ref, of type
RemoteRef.
– Essentially the stub class is just a wrapper for this remote reference.

Remote methods are dispatched through the invoke() method
on ref.
– This is passed an array of Objects holding the original arguments (in
general it also returns an Object).
– It is also passed arguments to identify the particular method to be
invoked on the server.

Essentially the stub wrapper is providing compile-time type
safety. The actual work is done in library classes that don’t
know the compile-time type in advance.
[email protected]
31
Marshalling of Arguments

Objects passed as arguments to invoke() must be marshaled
for transmission over the network.

Java has a general framework for converting objects (and
groups of objects) to an external representation that can later
be read back into an arbitrary JVM.

This framework is Object Serialization.
[email protected]
32
Serialization Preserves Object Graphs

Consider this binary tree node class:
class Node implements Serializable {
Node() {}
Node(Node left, Node right) {
this.left = left ;
this.right = right ;
}
private Node left, right ;
}

We create a small tree, d, by:
Node a = new Node(), b = new Node() ; // Leaves
Node c = new Node(a, b) ;
Node d = new Node(c, null) ;
[email protected]
33
Serializing and Deserializing a Tree
a
b

Write out the root of the tree:
out.writeObject(d) ;
c
d
a’

Read a node later by:
Node e = (Node) in.readObject() ;
b’
c’
e

The whole of the original tree is reproduced. Copies a’,
b’, c’ of the original sub-nodes are recreated along with e.
The pattern of references is preserved.
[email protected]
34
Referential Integrity is Preserved




This behavior is not limited to
trees.
a
In this example both b and c
reference a single object a.
Again the pattern of links is
preserved. When the root object is
reconstructed from its serialized
form, a single a’, referenced twice,
is also created.
Generally referential integrity is
preserved amongst all objects
written to a single
ObjectOutputStream.
[email protected]
c
b
d
a’
c’
b’
e
35
The Serializable Interface

Serializable is another marker interface. An object’s class
must implement Serializable if it is to be passed to
writeObject() (the library method that actually does
serialization). If it doesn’t, a NotSerializableException will
be thrown.
– Arrays are serializable if their elements are.
– Many (most?) of the utility classes in the standard Java library are
serializable.
– For example container classes as complex as HashMaps can readily
be serialized (assuming the user data stored in them is serializable),
and thus passed as arguments and returned as results of RMI methods.
[email protected]
36
Argument Passing in RMI: Summary

In general any object-valued argument or result of a remote
method must either implement Remote or Serializable.

If the argument or result implements Remote, it is effectively
passed by (remote) reference.

If it implements Serializable, it is passed by serialization and
copying. Referential integrity is preserved within the limits of
the arguments of a single invocation, as described above.
[email protected]
37
Mechanics of RMI: Summary




In principle most of the features that have been discussed in
this section are hidden inside the implementation of RMI. In
an ideal world you would not have to know about them.
In practice, to successfully deploy an RMI-based application,
you will probably need to at least be aware of some
fundamental issues.
You need to be aware of the existence of stub objects, and the
basic working of object serialization.
You should be aware that references to remote objects are
normally produced by creating a stub object on the server,
then passing this stub to registry and clients in serialized form.
[email protected]
38
Dynamic Class Loading
[email protected]
39
Byte Code Instructions for Stubs?


As we have seen: before any client can use an RMI remote
object, it must receive a serialized stub object.
The serialized stub contains a remote reference. Data fields of
the reference may include information like:
– The name of the host where the remote object lives,
– Some port number on that host, where the RMI run-time system is
listening for invocation requests.
– Any other information needed to uniquely identify the remote object
within its host.

One thing serialized objects do not contain is the actual JVM
instructions (the byte codes), that implement methods on the
local object.
[email protected]
40
Serialization Only Saves the Data

In general the Java serialization process stores all data fields
from the original object.

It does not store any representation of the code associated
with the methods in the object’s class.

When an object is deserialized (e.g. on some client), the client
JVM must have some way of loading a class file that does
contain this information.
– If it cannot find a suitable class file, the deserialization process will
fail. You will see a java.rmi.UnmarshalException thrown, with a
nested java.lang.ClassNotFoundException.
– When you are doing development using RMI, you will probably see
this exception a lot!
[email protected]
41
Copying Stub Class Files

In RMI, there are at least two ways to get the class files to the
client.

The straightforward approach is to manually copy class files
for all stub classes to the client: either put them in the current
directory on the client, or in some directory on the client’s
CLASSPATH.
– This approach is reliable, easy to understand, and perhaps the best
approach for initial experiments with RMI.

But eventually you may find this too limiting. One of the
benefits of the OO approach is supposed to be that the user
code (here the client) doesn’t need need to know the exact
implementation class in advance—only the interface. But
stubs are associated with the implementation class.
[email protected]
42
Dynamic Class Loading



A more general approach is to publish implementation class
files that may be needed by clients on a Web Server.
Although the serialized representation of an object does not
contain the actual information from the class file, the
representation can be annotated with a URL. This specifies a
Web Server directory from which the class file can be
downloaded.
When the object is deserialized, the client Java Virtual
Machine transparently downloads the byte codes from the
Web Server specified in the annotation. On the client side,
this process happens automatically.
[email protected]
43
Dynamic Class Loading
Serialized stub,
annotated with code-base:
http://myWWW/download/
Remote Object
(MyImpl instance)
Client
JVM
Server
Client
Request stub
class file
Web
Server
html/
download/
MyImpl_Stub.class
[email protected]
Server
(myWWW)
44
Remarks


In simple examples, the serialized stub will probably be
obtained through an RMI registry running on the server (the
same server where the remote object is running).
The two servers—the server where the remote object is
running, and the Web Server publishing the class files—may,
of course, be physically the same machine.
[email protected]
45
The java.rmi.server.codebase Property




We need a way to cause serialized object representations to be
annotated with suitably chosen URLs.
In principle this is straightforward. We set a property called
java.rmi.server.codebase in the JVM where the stub (or
serialized object in general) originates.
The value of this property is a code-base URL.
The RMI serialization classes read the code-base property,
and embed the URL they find there in the serialized
representation of arguments or results.
– Unless this JVM itself downloaded the class file for the object from a
Web server, in which case they embed the URL from which the class
was originally loaded.
[email protected]
46
Setting the Code-base

For example, our original HelloServer example might be run as
follows:
java –Djava.rmi.server.codebase=http://sirah.csit.fsu.edu/users/dbc/ HelloServer

This sets the java.rmi.server.codebase property to:
http://sirah.csit.fsu.edu/users/dbc/
This URL gets embedded in serialization streams created by the
HelloServer program.

If an object is subsequently recreated by deserialization in a different
JVM (and that JVM cannot find a local copy of the associated class
file) it will automatically request it from the Web server sirah,
looking in the document directory users/dbc/.
[email protected]
47
Security Managers



There is one more thing we need to worry about.
Before a Java application is allowed to download code
dynamically, a suitable security manager must be set. This
means a security policy must also be defined.
In general this is a complicated topic. We won’t go into any
detail: just give a recipe you can follow.
[email protected]
48
Setting the Security Manager

In an RMI application, if no security manager is set, stubs and
classes can only be loaded from the local CLASSPATH.

To enable dynamic loading, issue the command:
System.setSecurityManager(new RMISecurityManager()) ;
at the start of the program.

You should do this in any application that may have to
download code—in the simple examples considered so far
this means RMI clients that need to download stubs.

This isn’t the end of the story. You also have to define a new
property: the java.security.policy property.
– In simple cases this property is needed for clients, whereas
java.rmi.server.codebase is needed for servers.
[email protected]
49
Defining a Security Policy

The simplest security policy you can define is a plain text file with
contents:
grant {
permission java.security.AllPermission “”, “” ;
};

This policy allows downloaded code to do essentially anything the
current user has privileges to do:
– Read, write and delete arbitrary files; open, read and write to arbitrary
Internet sockets; execute arbitrary UNIX/Windows commands on the local
machine, etc.
– It is a dangerous policy if there is any chance you may download code from
untrustworthy sources (e.g. the Web).
– For now you can use this policy, but please avoid dynamically loading code
you cannot trust!
[email protected]
50
The java.security.policy Property

If the text file containing our security policy is called (for
example) policy.all, the original HelloClient example might
now be run as follows:
java –Djava.security.policy=policy.all HelloClient

Alternatively this property can be set inside the program using
System.setProperty().
[email protected]
51
Using Dynamic Loading: Summary

In principle, modifying your RMI application to allow dynamic
loading of stub classes is now straightforward:
– Install the stub classes in a Web Server document directory.
– Set the java.rmi.server.codebase property for the server application, to
reference that Web Server directory.
– Create a security policy file on the client.
– Set the java.security.policy property for the client application.
– Set a security manager in the client.

This also works for any classes (not just stubs) whose serialized
form may be communicated via remote method calls.
– You just need to reinterpret “server” and “client” application according to
the direction the serialized object moves—as “source” and “destination”
application.
[email protected]
52
Remarks




It probably seems a lot of work—just to avoid manually
copying one stub file from the server to the client.
But this facility for dynamically down-loading class files has
more far-reaching implications.
It is applicable not only to stubs, but any object passed
through a remote method call, where the class of the actual
object received is a specialization (subclass or implementation
class) of the type declared in the remote interface.
One can argue this kind of polymorphism is at the heart of
object-oriented programming. In this sense dynamic class
loading is a prerequisite for doing true object-oriented
programming with remote objects.
[email protected]
53
Other Features of RMI
[email protected]
54
The RMI Registry


The RMI registry is a process that normally runs on the
server.
At first sight the registry seems to have a privileged role in
RMI. Actually it is “just another” remote object.
[email protected]
55
The RMI Registry
Client
Server
Request
Reference
Client
Code
Registry Store
Reference
Remote
Object
[email protected]
56
Example: Jini



Sun’s Jini is a framework for spontaneous discovery of
services that exist in a LAN (for example), and for reliable
federation of these services.
It makes essential (and creative) use of aspects of RMI like
dynamic class loading and call-backs (discussed next).
The Jini lookup services generalize the RMI registry. In Jini
an arbitrary proxy object is installed in the lookup services.
– The proxy is not restricted to be an RMI stub. It can be any
serializable object, typically including remote references to an actual
server object.

The code for the proxy is downloaded dynamically by the
client, on lookup.
[email protected]
57
Example: Call-backs

A client can itself provide a remote interface, by creating its
own remote object.

It can then pass a reference to itself to a server. Now the
server can initiate communication by calling remote methods
on the client. These are sometimes called call-backs.

In general we see that RMI allows one to create complex
“webs” of interacting objects.
[email protected]
58
Synchronization




Where multiple clients may interact with the same object (this
means most useful services), one needs to pay attention to
issues of interference.
Remote invocations from different clients may execute
concurrently—in different threads—in the server program’s
JVM.
It can be a good idea to declare the implementation of remote
methods (in the definition of the implementation class) with
the synchronized modifier.
This avoids the dangerous situation in which methods are
being invoked simultaneously on a remote object by several
clients.
– Other clients will have to wait until the currently executing method has
completed—they will be serviced in turn.
– But now you must be wary of possible deadlocks.
[email protected]
59
Garbage Collection


For Java, an important issue is garbage collection, which
automatically deallocates memory for local objects.
Remote objects are also garbage collected as follows:
– A remote reference layer on the server keeps a reference count for each
locally held remote object implementation.
– A remote reference layer on the client notifies the server when its locally
held references to the object are no longer in use.
– When all references from all clients have gone (i.e. when the reference
count is zero), the server object is garbage collected.

But what if a client fails to notify the server?
– A client with a remote reference must periodically renew a lease with the
run-time system on the server.
– If the client holding the reference exits prematurely (without notifying the
server) it will also stop renewing its leases. If a lease is not renewed on
time, the server assumes the client has died, and the reference count is
decremented anyway.
[email protected]
60
Java RMI Performance
[email protected]
61
RMI for Parallel Programming

Some research groups developed software to support use of
RMI for parallel programming on non-shared-memory
platforms.
– Typically aimed at clusters with high-speed (e.g. Myrinet)
interconnect.

Well-known projects are JavaParty from Karlsruhe and
Manta from Vrije Universiteit (Amsterdam).
– JavaParty takes a more “purist” approach, in that it targets standard
Java Virtual Machines.
– Manta is based on a native compiler for the Java language.
[email protected]
62
The Problem



From the outset, the main problem these approaches must
tackle is the slowness of standard RMI.
The following benchmark results are quite old, but the basic
message probably hasn’t changed dramatically.
Taken from
More Efficient Serialization and RMI for Java
Michael Phillipsen, Benard Haumacher, and Christian Nester
ACM 1999 Java Grande Conference
[email protected]
63
RMI on a LAN

Two PCs: 350 MHz Pentium II, Windows NT, on Ethernet
(JDK 1.2):
[email protected]
64
Serialization Overhead

Part (but not all) of the explanation for poor performance is
the cost of object serialization:
[email protected]
65
KaRMI


As part of the JavaParty project, researchers from Karlsruhe
produced KaRMI, a “drop-in replacement” for Sun’s RMI.
KaRMI provides an optimized version of object serialization
(UKA-Serialization), and also improves the implementation of
the rest of the RMI stack.
– Greatly reduces the number of temporary objects created for a remote
method invocation.
– Eliminates some JNI calls.
– Reduces number of hash-tables used.

It also supports fast network hardware without going through
TCP/IP.
– Myrinet
[email protected]
66
KaRMI Benchmarks
[email protected]
67
Remarks


On Ethernet, KaRMI saves around 50% the overhead of
standard RMI (according to these timings).
The DEC results were obtained with a particularly ancient
JDK, and are certainly out of date. The reason for presenting
them is that they illustrate the ability of KaRMI to exploit
Myrinet-based communication technology like ParaStation.
– For HPC on clusters, this is probably the most important point!

As emphasized you can use KaRMI “standalone”, but it is
especially natural to use it in the framework of JavaParty.
– Speed of UKA-serialization dependent on existence of
writeObject()/writeExternal() methods, which are generated
automatically for JavaParty remote classes.

In any case KaRMI can be downloaded as part of the
JavaParty release, from:
http://www.ipd.uka.de/JavaParty/
[email protected]
68
Manta

Because Manta is a compiled language, a great deal of
optimization of RMI and serialization can be done at compile
time. This results in dramatically faster RMI implementation.
– A possible downside is that you must buy into the compiled Manta
mindset. This is rather different from the way most of the Java world
does things.

Information here is taken from
“Efficient Java RMI for Parallel Programming”,
Jason Maassen, Rob van Nieuwpoort, Ronald Veldema, Henri
Bal,Thilo Kielmann, Ceriel Jacobs, Rutger Hofman, 2000.
[email protected]
69
Manta RMI Timings

Note: “Sun RMI” column here is not timings for standard Java RMI. It is
an implementation of the Sun RMI protocol, optimized by the Manta crew,
then compiled with the Manta compiler!
[email protected]
70
Remarks


As advertised, these latencies are dramatically smaller than
for other RMI implementations, and in a good ball-park for
HPC applications.
The Manta software is available for download from:
http://www.cs.vu.nl/manta/
– Note it is provided in source form only, for compilation on a Linux
platform.
[email protected]
71
Special Topic: JavaParty
[email protected]
72
Transparent Remote Objects

The authors of
JavaParty—Transparent Remote Objects in Java
Michael Philippsen and Matthias Zenger
observed that Java doesn’t provide a straightforward
mechanism for parallel programming on distributed memory
machines, like clusters.
 Although method invocations on remote objects was
considered a natural Java approach, the JavaParty team note
that Java RMI has significant programming overheads.
– Writing separate interface and implementation code, initiating server
objects on multiple hosts, registering them and looking them up, etc.

JavaParty effectively specializes RMI to cluster-like
environments, and provides a preprocessor and run-time
environment to do much of this work automatically.
[email protected]
73
The remote keyword


JavaParty makes one innocent-looking change to the Java
language—a new modifier is allowed in class declarations:
remote.
The JavaParty runtime will automatically allocate a remote
object (any instance of a remote class) to a host in the cluster
environment.
– Typically different to the host that create the object.


Any method called on a remote object is implicitly a remote
method invocation.
So there is no need to initiate servers manually, or register
remote objects: they are created and referenced in a program
exactly like ordinary Java objects.
– This doesn’t necessarily mean they behave exactly like ordinary Java
objects, see later discussion.
[email protected]
74
JavaParty Hello
package examples ;
public remote class HelloJP {
public void hello() {
System.out.println(“Hello JavaParty!”) ;
}
public static void main(String [] args) {
for(int n = 0 ; n < 10 ; n++) {
// Create a remote method on some node
HelloJP world = new HelloJP() ;
// Remotely invoke a method
world.hello() ;
}
}
}
[email protected]
75
Running JavaParty Hello

On Linux, create a “nodes” file in your home directory, e.g.
$ cat ~/.jp-nodefile
smoky.ucs.indiana.edu
atlas.ucs.indiana.edu

On Linux, compile the program with the jpc command, and
run it with the jpinvite command
$ jpc –d classes –s HelloJP.java
$ jpinvite examples.HelloJP
Hello JavaParty!
Hello JavaParty!
…
[email protected]
76
Remarks


Compared with using RMI, this is impressively
straightforward.
Note, however, that it is specialized to a cluster-like
environment. For example it assumes a shared file system.
– This simplifies various problems that arise in the distributed setting.
For example the complexities of dynamic class loading from Web
servers aren’t required (or supported) in JavaParty.


To run on a LAN under Linux, ensure ssh login to remote
nodes is possible without password, ensure no intervening
firewalls.
In my experience the classes/ folder should be added to the
CLASSPATH as an absolute file name, in your ~/.bashrc or
equivalent.
[email protected]
77
Semantics of JavaParty


JavaParty does more than just put syntactic sugar around the RMI model of
remote objects.
It doesn’t require remote operations to be specified through a Java interface.
– It is classes that are remote.

Remote methods are not required to throw RemoteException.
– According to Waldo et al (cited earlier) we can interpret this as meaning
JavaParty is not exactly for distributed programming.

For these and other reasons, JavaParty can support several kinds of remote
operations that simple RMI does not, e.g.:
– Static methods can be called remotely.
– Fields (instance and static) of remote classes can be accessed remotely, using just
the ordinary Java syntax for field access.
– Recent versions of JavaParty support a sophisticated feature called transparent
distributed threads.

However all these things come at some cost, and there remain some significant
differences between the semantics of a JavaParty program and the
corresponding Java program (without the remote keywords).
[email protected]
78
Translation Issues

A JavaParty program is effectively translated to a Java
program that uses standard RMI. Because of the semantics
just discussed, the translation scheme is quite complex, e.g:
– Remote method calls all need wrappers that handle
RemoteExceptions that are presumably never thrown.
– Every remote class gives rise to several classes in the translated code,
e.g. the interface and implementation class for a remote “class object”
that handles static method, and acts as kind of a factory for remote
instances.
– Accessor methods (get/put) must be defined for fields of remote
classes, and the translator must convert uses of these fields into calls to
the accessor methods (need special accessors for array elements).

The current modern JavaParty compiler is an adapted version
of the gj compiler (apparently not open source?)
[email protected]
79
Some Features


A significant difference between the semantics of a Java program and a
similar-looking JavaParty program is that generally arguments and results
of methods on remote objects are passed by value (because they reduce to
RMI calls).
Because access to remote fields goes through implicit accessors, which are
remote methods, this feature also affects access to fields. As an odd case,
suppose a is an object from a class with an array-valued field arr, then:
int [] localArr = a.arr ;
localArr [0] = 23 ;

If a is a Java object, this modifies the field a.arr. If a is a JavaParty
remote object, it just modifies a copy—leaves the field unchanged.
Sometimes JavaParty gets described as a distributed shared memory
model.
– This may be slightly misleading—if you naively wrote an OpenMP-style dataparallel program in JavaParty, it would probably be very inefficient because
every access to a shared array would go through remote get/set methods.
[email protected]
80
CartaBlanca

CartaBlanca , from Los Alomos National Lab, is a general purpose nonlinear solver environment for physics computations on non-linear grids.
“Parallel Operation of CartaBlanca on Shared and Distributed Memory
Computers”
N. Padial-Collins, W. VanderHeyden, D. Zhang, E. Dendy, D. Livescu.
2002 ACM Java Grande/ISCOPE conference.



It employs an object-oriented component design, and is pure Java.
Parallel versions are based on partitioned meshes, and run either in
multithreaded mode on SMPs, or on networks using JavaParty. Here we
are interested in the latter.
These results are a Linux cluster of Compaq DL360 nodes, each with two
1GHz pentiums. Network is GigE.
– The following results are from a pre-publication version of the paper cited,
and should presumably be taken as indicative only.
[email protected]
81
Broken Dam Benchmark Results
Best speedup: 3.64 on 8 processors
[email protected]
82
Heat Transfer Problem

Solves transient heat equation on a square domain.
Best speedup: 2.6 on 8 processors
[email protected]
83
Remarks

Operation of the program described as follows:
– The main method spawns threads for each mesh partition.
» In the RMI/JavaParty implementation, these threads will invoke a remote
method to distributed the work.
– The threads communicate through separate (remote) objects—calling
getter and setter methods on these objects.
– There is a “reduction” communication object for operations like
summing data across all threads.
– A boundary communication object is used to update edge nodes shared
by adjacent partitions.

Source is available from
www.lanl.gov/projects/CartaBlanca/overview.html
[email protected]
84
JavaParty: Summary

If you are writing parallel programs for a cluster, writing the
program using JavaParty will typically be much more
convenient than using JavaRMI directly:
– No need to create separate interface and implementations, and use
rmic.
– No need to publish class files on Web servers.
– No need to explicitly use RMI registry.
– Don’t have to handle RemoteException.

On the other hand, JavaParty only automates the distribution
of code. It does not provide much help with parallelization.
You still have to “manually” divide up the work, start Java
threads, think about communication.
[email protected]
85