C414: Another excellent accepted paper

Referee 1 ************************************************************

Review of:
More Efficient Serialization and RMI for Java

a)Overall Recommendation

Accept

b)Comments for the authors

The paper describes how the performance of Java RMI can be drastically
improved
using plug-in replacements. This work undoubtedly is very useful to
the high-performance Java community, which certainly justifies publication
in this special issue.

I also have several comments on the paper. The others should take into
account that this publication is going to appear in an archival
journal on parallel programming in general, whereas the JavaGrande'99 paper
was intended for a more specialized (and less formal) forum. More
specifically
I have the following recommendations:

 - The paper (in particular the related work section) ignores the large
amount
   of research that has been done outside the Java world on high performance
   communication protocols.  Many of the ideas implemented in KARMI and
   UKA-serialization have appeared before in other languages and systems
   (e.g., see Thekkath's work on RPCs, Split-C, other object-oriented
   languages like Concert or Jade).
   This does not make the work of the authors less interesting, but they
   should make more clear which ideas are new and which ideas (from other
   systems) have been reused for Java. This issue should also be addressed
   in the conclusions section: summarize which new problems Java RMI
introduces
   besides the ones that are already known and solved by other systems.

 - Section 3.7 is very JDK specific; it contains too many JDK details for
   the general parallel computing audience. This part is new compared to
   the JavaGrande version, but I do not find it very suitable for CP&E.
   I would write this in a more abstract and concise way, and put the
   JDK details elsewhere (eg in a report).

 - The benchmark results lack a discussion of the throughput that is
   achieved by the various RMI implementations. I would strongly suggest
   to add a throughput test and to specify the number of memory copies
   that each RMI implementation makes (since this largely determines
   throughput on a high-speed network).

 - The paper sometimes is too informal for a journal. Sentences like
   "please contribute additional RMI benchmark programs" clearly do not
   belong in an archival journal.

Sore details:
- the name of Matt Welsh is misspelled consistently (as Welsch), both in the
  text and in the references
- reference [19] has been published in PPoPP'99

Referee 2 *************************************************************

a) Overall Recommendation:

accept

b) Comments to the authors:

The paper describes a plug-in replacement for RMI, called KaRMI,
and a similar replacement for Java Object Serialization, called
UKA-Serialization. Both replacements offer significant performance
gains over Sun's implementation and seem straightforward to use
with existing Java RMI applications. KaRMI is also able to use
other communication technologies besides TCP/IP, thus increasing the
benefit for users of high-speed networks like Myrinet.

This is a well written and technically sound paper. It was fun to
read it for this review! The authors first present a detailed analysis of
the shortcomings of RMI and Object Serialization, then address each
of these problems with a suitable fix, and finally back up their claims
with an extensive set of experimental results that show the improved
performance.

The high practicality of this work is demonstrated by the simplicity with
which KaRMI can be used to replace the existing RMI in JDK.
Hopefully, some, if not all, of these improvements will make it into Sun's
next release.

Related work also seems comprehensively handled.

If anything needs to be improved, perhaps it should be Section 3.7, where
the
authors talk about design issues regarding their UKA-Serialization.
I found this section a little hard to understand without detailed knowledge
of the implementation of Sun's Object Serialization. A few code examples
might make this section easier to read.

Also, there is a grammatical mistake in the 2nd paragraph of Section 4.1:
"Making them a part of the API and thus visible at the application level,
causes that ..." where "causes that" should be replaced, e.g. by "means
that".

Finally, in their conclusion the authors state a median savings of 45% for
PCs with Ehernet, which they claim to be a sixfold improvement... Shouldn't
that
be a twofold improvement, or did the authors really mean the 85% savings for
DEC Alpha a few lines further down ?

Referee 3 ********************************************************

C414 JGSI Review
Overall recommendation: accept
Comments:

Nice paper.  It would be interesting to see more application results.
I was quite disappointed with paraffins when I personally looked at
it: it wasn't doing a whole lot.  I understand that getting the entire
RMI benchmark suite takes some time, so you might want to consider
doing it for a later submission.  The paper is fine as is.