Subject: Update Java Grande Report

From: Michael Philippsen <[email-masked]>
Date: Fri, 04 Jun 1999 21:56:09 +0200

Geoffrey:

here is my personal view of the progress situation. It would be perfect
if you could fill in the holes (or have Martin, Vladimir or Mark do so).
I hope you mention me in the authors section of the update :-)

In <<double angles>> you can find areas where I cannot provide
the text....and need other people's input.

Regards,

     *Michael.

European Funding Initiative:
============================

<<The Updated Report should have a short section on the European
funding initiative by Mark Baker. Please ask [email-masked]>>

Numerics Working Group
======================
<<In case you intend to mention Jose's complex numbers in the numerics section of
the update, here is some more information on that issue:

The JavaParty group at the University of Karlsruhe, Germany, has
developed a preprocessors the adds a new basic type complex to Java
and maps the resulting code back to pure Java.

Compared to code that uses Complex objects and method
invocations to express arithmetic operations the new basic type
increases readability and it is also executed faster. On average, the
versions of our benchmark programs that use the basic type outperform
the class-based versions by a factor of 2 up to 21 (depending on the
JVM used).

More information can be found at
 http://wwwipd.ira.uka.de/JavaParty/

Concurrency and Applications Working Group
==========================================

The Concurrency and Applications Working Group (hereafter ACG) has
focussed on the following issues:

1- Critical JDK issues
2- Benchmarks
3- Message passing
4- Other parallel and distributed computing issues

After the public dissemination of the Java Grande report at
Supercomputing in Orlando, progress has been made in most of these
areas.

1- Critical JDK issues
----------------------

a) Performance of Object Serialization

In the Orlando report, the performance problems of object
serialization have been discussed thoroughly. Object serialization is
the basic mechanisms that is used by Java's RMI (Remote Method
Invocation) to convert Java objects into a byte stream
representation and vice versa. Hence, the performance of object
serialization is crucial for Grande applications that need distributed
parallel machines.

The JavaParty group of the University of Karlsruhe, Germany, has
designed and implemented a drop-in replacement for the
JDK-serialization, called UKA-serialization, that can be used in
situations where persistence is not an issue. The UKA-serialization is
written in Java and reduces the serialization overhead by 81\% to
97\%.

Most of the individual show-stoppers mentioned in the Orlando report
have been solved in that implementation. For example, the
UKA-serialization uses explicit marshaling instead of reflection, it
uses a slim type encoding, it adds an additional type of
reset-operation that avoids costly retransmission of type information,
and it implements a more efficient buffer handling.

More information on the UKA-serialization can be found at
 http://wwwipd.ira.uka.de/JavaParty/
and in
 Bernhard Haumacher and Michael Philippsen. More Efficient Object
 Serialization. In Parallel and Distributed Processing, LNCS 1586,
 pp. 718-732, International Workshop on Java for Parallel and
 Distributed Computing, San Juan, Puerto Rico, April 12, 1999.

The JavaGrande forum has discussed the central ideas of the
UKA-serialization with Sun's RMI group in Burlington. It seems likely
that some of the ideas will be incorporated in future releases of the
JDK. In particular, it is likely that there will be a way to switch to
a slim type encoding.

b) Performance of RMI

In the Orlando report the performance problems and other difficulties
of RMI have been discussed in depth.  Although Grande applications
that require parallel computers need an efficient use of non-TCP/IP
communication hardware, the current RMI does not provide any
support. Moreover, since the current RMI has been designed and
implemented with rather slow internet-connections in mind, the design
includes many mechanisms that deal with instable or slow networks.

For Grande applications, access of high-performance networks is
essential. Moreover, in closely connected cluster settings, a lot of
RMI's overhead can be traded for speed.

The JavaParty group of the University of Karlsruhe, Germany, has
designed and implemented a drop-in replacement for the RMI, called
KaRMI, that can be used in situations where persistence and
TCP/IP-addressing mechanisms are not an issue. KaRMI is completely
written in Java. In combination with the UKA-serialization, KaRMI
saves up to 71% of the time needed for a remote method invocation
between two PCs connected by Ethernet. Between two Dec Alphas
connected by a Myrinet-based ParaStation network, a remote method
invocation can be executed within 80 mirco seconds.

In addition to being as compatible as allowed by the requirement of
support for non-TCP/IP networks, KaRMI comes with simple and
documented interfaces. Several transport technologies can be mixed, an
optimized distributed garbage collector can be plugged in which handles
combinations of different communication technologies.

More information on the KaRMI can be found at
 http://wwwipd.ira.uka.de/JavaParty/
and in
 Christian Nester, Michael Philippsen, and Bernhard Haumacher
      A More Efficient RMI. In Proc. ACM 1999 Java Grande Conference,
 San Francisco, June 12-13, 1999.

The JavaGrande forum has discussed the central ideas of KaRMI with
Sun's RMI group in Burlington. It is unclear whether any improvements
will make it into the official RMI implementation.

The following issues are still open:

- Still needed are mechanisms for a closer interaction with Java's thread
  scheduler, especially if the communication hardware operates in user level.
- The RMI source code is still unavailable.
- The internal layers of RMI are still undocumented.
- It would be interesting to see, whether the improved RMI could used by
  IBM's San Francisco project. This project, unfortunately, uses internal and
  undocumented classes of the RMI implementation.
- Class Compatibility Problem, see Orlando report
- Dynamic Class Loading from Remote Hosts, see Orlando report

Other papers that contain information relevant to Java Grande are:

        Ronald Veldema, Rob van Nieuwport, Jason Maassen, Henri E. Bal,
 and Aske Plaat. Efficient Remote Method Invocation,
        Technical Report IR-450, Vrije Universiteit, Amsterdam,
 The Netherlands, September 1998.

 Chi-Chao Chang and Thorsten von Eicken. Interfacing Java with
 the Virtual Interface Architecture. In Proc. ACM 1999 Java Grande
 Conference, San Francisco, June 12-13, 1999.

2- Benchmarks
-------------
- <<The EPCC has been busy. Please ask Martin Westhead.>>

- The JavaParty group at the University of Karlsruhe, Germany, has put
  together nn RMI benchmark. The collection is available from

 http://wwwipd.ira.uka.de/JavaParty/

3- Message Passing
------------------
- <<please ask Vladimir to summarize>>

---

From: "George K. Thiruvathukal" <[email-masked]>
Date: Fri, 04 Jun 1999 14:14:14 -0500

Everyone:

I think, if we are going to issue an update to the report, someone needs to take
ownership for each of the major sections. I am very happy to take ownership of
incorporating the addenda (or revisions) to the entire document; however, this time
around, I think it would be helpful if one person from each working group takes
initiative to manage the feedback. For the next several days, I am going to be
somewhat (pre)occupied with my tutorial for Java Grande 1999, so it is important to
me that others do help with the process.

The big ticket items seem to be:
- ACG RMI issues
- Numerics issues
- Message Passing Interface
- Benchmarking

It seems like the addenda should also focus on trying to articulate (clearly) the
feedback we have received from Sun. There was the one meeting in Burlington between
ACG (+Roldan) and Sun people and then one (or two) meetings between Numerics and Sun
out west. I had written a somewhat detailed memo w.r.t. the feedback given to ACG,
and I seem to recall Roldan/Ron having sent some notes. Are we fully satisfied with
the outcome at the macro level? Do we have buy-in?

George