I enclose 3 Referee reports on your paper. We would be pleased to accept it and could you please send me a new version before November 5 99 Please send a memo describing any suggestions of the referees that you did not address Ignore any aggressive remarks you don't think appropriate but please tell me. I trust you! Thank you for your help in writing and refereeing papers! Referee 1 *************************************************** Subject: C436 JDSI Review Title: Javia: A Java Interface to the Virtual Interface Architecture Authors:Chi-Chao Chang and Thorsten von Eicken a)Overall Recommendation ACCEPT b)Words suitable for authors ---------------------------- Some minor issues: - at the end of section 1, please explain what pMM and Jam are. - first line of section 2.2.1: "dissertation" --> "paper" or "article" - section 3 has only three subsubsections 311 312 313. Please use 31 32 and 33 instead. Same for section 4. - In the listing on p4 lines 7 and 8 are missing. This is problematic since the text specifically discusses "lines 7-12". - The last paragraph on p6 discusses "lines 15-19". Unfortunately these lines do not refer to a reasonable section in the listing on p6. - 3rd paragraph on p7: "jbuf" has not been mentioned before. "Accessing these buffers ... require*s*..." - Section 411: it should be "Table 2" instead of 1. - 2nd line of section 5.2: space missing after "[AC95]." - Please use $\mu$s for micro-seconds and avoid "us". At least be consistent. - last paragraph of 6: KaRMI has a latency of 80us. What is JDK 1.4? - References: please provide page numbers for all articles, not just for [vEBB+95] Updated versions of [NPH99] and [WC99] will appear in the same issue of CPE. Change refs. - Table 1: micro-secs instead of us. Please combine with table 2. - Figures 2 and 3 consume too much space. I recommend to combine them (side by side) with only one window that explains the shapes of the bullets. Same for Figures 5 and 6. And 11 and 12. - please combine figures 1 and 4. When presented next to each other it is easier to see the differences. - Do you have an idea on how to combine all the information of figures 7-10 into one figure? If not, please use the same border line for all 4 figures. Referee 2 ************************************************************ Subject: (C436) JGSI Review 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. Referee 3 ************************************************************* Subject: C436 JGSI Review Javia: A Java Interface to the Virtual Interface Architecture Chi-Chao Chang and Thorsten von Eicken a)Overall Recommendation Clear and well-organized paper. Minor corrections and comments below. b)Words suitable for authors Section 2.1, last sentence in para 2 "The architecture also supports for interrupt-driven reception" ^^^ Typo? Section 3.1.1 Something has gone wrong with the line-numbering in the interface code. Lines 7 and 8 (referred to in the subsequent text) are missing. Same section, the authors write: "To post a Java byte array transmission, Javia-I gets a free ticket from the ring [...] to receive [...] Javia-I obtains the ticket that corresponds to the head of the VI queue" I'd like to know what this looks like in user code for the `sendPost', `revPost' cases. Are necessary entry-points missing from the API given above? Section 4 In Sun's JDK, using standard JNI, I'm not aware there is any mechanism to allocate an array in native code, then view it as a Java array (which is what the authors do here). Can the authors comment on this? Section 5.1 In the example code, what is `r' (= n/p, perhaps)? I don't think `redDoubleArray' has been defined earlier. Paragraph prior to 5.1.1, authors state: "performance [...] using Marmot is about 70 Mflops for 64x64 matrices, and 45 Mflops for 256x256 matrices (compared to JDK 1.2's 55Mflops and Jview's 37Mflops for same size matrices)" *Which* size for JDK/Jview---64x64 or 256x256? Section 5.2, first para. A citation label "[CCH+96]" appears. It isn't defined in the bibliography. Same section para 4, last sentence: "Java *knows* whether the GC is copying after [...]" I didn't understand this sentence. It might be worth adding some brief explanation of how copying garbage collectors work, for the uninitiated. Section 6, first para: "This re-direction incurs on level of indirection [...]" ^^ Typo? c)Words for me if necessary None.