Subject: (C436) JGSI Review
Resent-Date: Thu, 30 Sep 1999 23:16:23 -0400
Resent-From: Geoffrey Fox <gcf@npac.syr.edu>
Resent-To: p_gcf@npac.syr.edu
Date: Sun, 12 Sep 1999 14:20:10 -0700
From: Matt Welsh <mdw@cs.berkeley.edu>
To: Geoffrey Fox <gcf@npac.syr.edu>

Paper number: C436
Title: Javia: A Java Interface to the Virtual Interface Architecture
Authors: Chi-Chao Chang and Thorsten von Eicken

Overall comments:

This paper describes a Java interface to a commercial implementation of
the VIA cluster communication architecture. Two implementations of Javia
are discussed: the first relies upon the JVM's native code interface to
abstract access to the VIA layer, and the second relies upon a modification
of the Java compiler to provide a special class representing pinned
communication buffers.

Overall this is an excellent paper; it is well-written and presented, and
contains the right amount of analysis. My two concerns are (1) a lack of
discussion about the design methodology of the two Javia implementations,
and (2) some confusing terminology used to present the performance results.
These concerns can be easily addressed.

Comments for authors:

First off, it seems that this paper is not completely up-front about the
design methodology of Javia. It seems that your particular design was
motivated by several factors, primarily the use of a "closed" C-based
VIA library as well as the Microsoft Marmot compiler. As you know, Jaguar
took a very different approach since we had a "closed" JVM but an open
JIT compiler, and the VIA implementation itself was open, meaning that
the Java application could be compiled to access the hardware directly
(rather than through a C-based API).

This paper fails to discuss what I think are two important design aspects
of Javia:

        1) The incongruence between the C-based VIA API and the Java API,
           and how that was overcome by an approach which is half a set
           of wrapper methods and half a means to directly map VIA buffers
           into the application as Java arrays. There are some deep concepts
           here, but the paper doesn't talk about them in those terms.

        2) The implementation of the Javia-II "ViaBuffer" class, which
           seems to require modifications to the compiler and garbage
           collector. In fact the implementation of this class
           (particularly the "toByteArray" and "toIntArray" methods)
           is not discussed at all! What was required to implement this?
           How general is the approach, and how would it apply to other
           kinds of communication or I/O systems? Is the implementation
           portable or highly dependent on the Marmot compiler?

In other words, some of the details of Javia come across as being a hack
rather than something which was designed to deal with deeper issues in
implementing high-performance systems software in Java. It would be nice
to have a bit more discussion about these issues. Obviously Javia is not
just a hack, but it would be nice to see what the deeper implications of
its design are, and how they could be adopted into other systems.

My other concern is in the presentation of the performance results.
The "two variations" of the 'send' call in Javia-I are not obvious from
the API specification; is this the meaning of the 'tag' argument?
Also, the labels used in your tables and figures for performance results
("raw", "copy", "pin", etc.) are a little confusing. The definitions are
squirrelled away in the text; it would be nice to make the labels a bit
more user-friendly (e.g., "raw" could be "C-based VIA" and "copy" could
be "Copy on xmit"). Also, the distinction between JDK and Marmot could
be made clearer -- to most, "JDK" means "Java Development Kit", not the
Microsoft JVM with JNI!

I think that your comparison of Javia and Jaguar is fair, considering the
scope of this paper, but I think a number of interesting issues remain.
For instance, Jaguar allows the Java application to directly manipulate
hardware resources from Java, while Javia relies upon a C-based API for
most of its functionality. Also, without any implementation details
about Javia's "ViaBuffer" class, it is not obvious what this has in
common with Jaguar's "external objects".

Again, this is a very good paper and it is clear that Javia had a good deal
of effort put into it. Most of the changes above are relatively minor.