The old paper layout: Message-Passing in Java 1. Introduction 2. Visper 3. The Console 4. The Backend 4.1 Daemon 4.2 Worker 5. Message-Passing Primitives 6. Remote Processes and Groups 7. Example Program 8. Performance 8.1 Speedup 8.2 Point-to-Point Communication 9. Metacomputing in Java 10. Conclusion References The new paper layout: An Open System for SPMD Programming 1. Introduction 1.1 Native Message-Passing Systems 1.2 Java Programming Model 1.3 Motivation 2. Visper 2.1 The Console 2.2 The Backend 2.2.1 Visper Daemon 2.2.2 Resource Manager 2.2.3 Worker 3. Programming Model 3.1 Message-Passing Primitives 3.2 Remote Threads 3.3 Remote Process and Remote Group 3.4 Group 3.5 Remote Thread Migration and Checkpointing 3.6 Example Programs 3.6.1 The MPI Execution Mode 3.6.2 The RT Execution Mode 4. Performance 4.1 Speedup 4.2 Point-to-Point Communication 5. Related Java Systems 6. Conclusion References Appendix ----------------------------------------------------------------------- Referee 1 2) Accept provided changes suggested are made F: Referee's Comments (For Author and Editor) Paper Number: The papers presents the work on visual parallel programming and runtime system for networked computers. The tool like this is a valuable contribution to the field and worth to publish. However, it is beneficial to make a few changes. 1. Title-- It is very general & does not much convey what the work is about. I think the author need to find out a suitable title better reflecting the work. ---I hope you will find this one more appropriate 2. Explanation.... The entire body of paper explanation uses just plain words. It is worthwhile to include code segments, list class structure, interfaces so that user knows what he has at his/her disposal for using system like this. ---I have included API classes, diagrams, and 3 code examples 3. Case System... There is need of an application which uses the mentioned system. Can authors describe one ? If so, please do. ---Visper is a general purpose environment for OO and (multistyle) parallel and distributed programming and agents. It is still under development, and was primarily used in teaching. While we can think of an application similar, but maybe not as ambitious as Nexus or Globus, the truth is that it has not been used for anything similar yet, so I would rather refrain from it at the moment. 4. I think the section name 9 should be like "Related Works/Systems" as this is what actually it is. ---DONE (Section 5 now) 5. If the reader is interested, From where he can get the described software. I mean, mention about the website for download the software.. ---DONE (see Conclusion) G: Presentations Changes Paper Number: Title Changes: NEED TO CHANGE THE TITLE ----------------------------------------------------------------------- Referee 2 2) Accept provided changes suggested are made GENERAL COMMENTS The author has not made it clear what the purpose of Visper is: 1. Is the goal Java + message passing? If so, he should reference Technical Report JGF-TR-03: "MPI for Java", Nov, 1998. see www.javagrande.org ---DONE (Section 5) 2. Is the goal to provide a software tool for metacomputing? If so, he should reference and relate his work to the work that has already been done in this area with GLOBUS, Legion, and the work in NASA on the Information Power Grid. ---DONE (Section 1.1). I think that comparing Java systems to these is unfair, as the Java systems are new and do not have that many people working on them. To my knowledge, none of the pure Java systems can match any of the mentioned systems, at the moment. That's why my related work is titled "Related Java Systems". The author needs to clearly point out what is new with his work and clearly describe the results that are of interest to this community. ---To summarize: Pasadena group recommendations, Visual Language, Message-Passing library implementation, process creation and control. In the paper, Section 1.3, Section 3 (3.1, 3.3, 3.4), Section 5 I gave this paper to a number of others and asked for their comments. Everyone agreed that the paper was poorly organized and difficult to understand. I suggest that the author decide the main points he wants to convey and then write the paper making these points clear and leave out all unneeded details and unrelated items. ---I don't know what unneeded details, in particlar. My idea was to present all the components the tool comprises, but concentrate only on those relevant to message-passing in Java. The other parts were described in the referenced papers. However, I have restructured the paper and some sections (1 and 5), and added more details. I hope the paper is more readable now. MISCELLANEOUS DETAILED COMMENTS 1. Section 9 should immediately follow section 1 and be titled Background. ---I think it's better the way it is. I can directly compare against Visper 2. It appears that DOGMA is similar to Visper. The difference should be carefully explained. ---See Section 5: Related Java Systems. In my opinion, the goals of Visper are quite different to those of DOGMA. I believe that Section 5 reflects better now the aims and ideas of the mentioned systems, as I understand them. 3. Abbreviations should be spelled out the first time they are used. ---DONE 4. What is the purpose of the Console? Is it primarily for aiding in the writing of parallel programs? If so, many have done something similar and in all the cases I'm aware of, the generated code often executes very inefficiently. Is this also true for Visper? ---I thought that this might be an unneeded detail as it belongs more to visual programming than message-passing in Java. But, since you have mentioned it here, rather than getting into detail description, I have added two new references (21 and 29) that describes this topic and our research. Also in Introduction, I have pointed out that this is about visual composition. 5. First sentence in section 4.1. Change 'daemon' to 'Visper daemon' throughout. ---In Section 2 (2.1.1) I put a mark that states: Visper daemon (or just daemon for short). In the text I use Visper daemon where I beleive there is ambiguity. 6. I suggest that the scheduling algorithm(s) used be modular so different scheduling algorithms can be easily implemented into Visper. ---Visper uses agents (Section 2.2.2) 7. The examples in section 7 are not clear at all. I suggest that the author revise these and give the revised examples to others who are not familiar with Visper to find out if they are understandable. ---This is section 3.6 now. I hope it's better. 8. Section 8.2. I suggest that the author refer to COMMS1 as the Ping-Pong test since this is what is commonly used in the literature and since it conveys its meaning easily to the reader. ---This is Section 4.2, now. I'd rather stay with COMMS1. That's used in the reference [9]. I have also added "Ping-Pong" in brackets to it (paragraph 3). 9. Figure 4 in section 4 is poorly done. It would be better to have two separate graphs or just choose one of the graphs and present it. ---There are two examples now (Figure 8 and 9). Plus a label against each of the axis, not just the unit. 10. Tables 1-4 are difficult to understand. I suggest the author think carefully what information he wants to convey and how to best convey this information clearly to the reader. ---There are two figures now (Figure 10 and 11 and Table 3 and 4) 11. Why is the latency roughly two orders of magnitude higher for Visper than MPI? Is there something inherent in Java that causes this? If so, this would be an interesting result. ---The paragraph below Figure 10: This is due to a high socket .... Also, there is a reference to a paper with more details [30]. -------------------------------------------------------------------------------- Referee 3 Referee Recommendations: 1) Publish as is... X 2) Accept provided changes suggested are made 3) reject F: Referee's Comments (For Author and Editor) Paper Number: Section 4.2: "[...] the user can refresh the stored classes without restarting the worker" Does this refer to reloading of classes (ie, reloading modified versions of the same class into the same JVM). If so, what is the mechanism? (I didn't know this was supported by current JVMs) ---Explained in Section 2.2.3. We use a customized class loader. Section 5: In view of the title of the paper, maybe a section on Message-Passing primitives could go into a little more detail. ---Section 3.1 has been revised compared to the old paper (Section 5). Section 6, 1st paragraph: "Visper, provides two modes of execution: the MPI mode and the dynamic RT." This distinction remained unclear to me. Maybe it is something like the static SPMD style (like MPI 1) verses dynamic spawning of processes (as in MPI 2). The terminology for these modes could be improved. ---Section 3.5 now. I hope this is better. "Instances of these classes serve as peers to the remote threads." Perhaps you mean "proxies" rather than "peers"? ---I would rather called them peers than proxies as they have no knowledge of the objects they represent. But, I rephrased the sentence to avoid confusion. (Section 3.3 now) "VRemoteGroup rgrp = new VRemoteGroup(RemoteThreadClass, vgrp);" What is the first argument of the constructor? (The name `RemoteThreadClass' suggests it is a class, but that can't be right.) ---It's a Class: RemoteThreadClass.class (see Section 3.6.2). This way the compiler can check if that is a valid class or not. If a string, this can be only a runtime error In any case, please extend this a little to show how `rgrp' is used (otherwise the example isn't very helpful to me). ---Section 3.4 Section 7: Presumably `VWorld' is a subclass of `VGroup'? ---Figure 6. Now it's called RTWorld and RTGroup Perhaps remind us what `VComms' is here. (It was mentioned in passing in Section 2, but I had forgotten by this point.) ---I added comments to the code (Section 3.6 now, before Section 7). Also, more details are in the description, I believe. I think you should give some explanation in the text of the classes `VDataSend', `VDataRecv', since they appear in the example. What is the first argument (value 10) of the `ds', `dr' constructors? ---Section 5 before is Section 3.1 now. Figure 5 shows the classes, and there is the VData class definition Section 8, paragraph 1: "Since the Solaris version does not support just-in-time compilation (JIT), the just-in-time compiler was disabled for the test, except where noted" This disturbs me. Without a JIT, the sequential Java program is typically so slow that speedup benchmarks (reported in 8.1) are fairly pointless. ---See introduction to Section 4, last sentence. I agree with you, but this is the best I can do at the moment. I have added one more example (Figure 9) that was also done on PCs, with JIT. However, I don't have a native MPI library for Windows to make a fair comparision with RTComms. Section 8.1: See the previous comment. I think speedup is uninteresting here. You should give actual execution times. ---The left Y-axis represents the actual time (Figure 8 and 9). I have added a label "time(ms)" to clearly designate that. "It is interesting to compare these speedup values to one obtained by the MPICH" Do you mean a C/Fortran program using MPICH? Please clarify. If yes, please give the actual timings (not speedup) for this version compared with Java. In any case a comparision with C or Fortran is highly desirable. ---Yes. See also the text below Figure 8. "For the first example, the speedup was [...]" I was confused by this point about what are the first and second example. Maybe make a properly organized table, comparing MPICH/Visper. ---I hope this is better now "However, the computations times were [...] respectively [...]" Again, I didn't really know which computation times you meant: ie, what is respective to what? Please present this data more clearly. ---I hope this is better now G: Presentations Changes Paper Number: Title Changes: *** The title must be made more specific. *** Abstract Changes: First sentence: Change "by the name of Visper" to "called Visper"? ---DONE Reference Changes/Additions: Other Comments (Grammar, etc.): Section 1, paragraph 1, 3rd sentence: "The problem is [...]" I'm not sure you can claim this is *the* problem. I suspect other problems, like overcoming network latency, are even harder in practise. It's *a* problem, certainly... ---DONE "One of the problems ..." 2nd paragraph: "The problem with both systems [...]" Same comment. ---Section 1.1, 1st paragraph: "Both systems require..." 3rd paragraph: "[...] the world of computing has become richer for [...]" Perhaps "the world of computing has been enriched by" would read better. ---Section 1.2, 1st paragraph Same para: "[...] primitives based on the monitor and conditional paradigm by C.A.R. Hoare" Not sure what you mean by "monitor and conditional" paradigm. I believe Hoare's original monitors allowed a conditional guard expression, but this isn't implemented in Java monitors. ---Section 1.2, 1st paragraph, at the end Same para: "Java interpreter that operates on virtual memory executes the binaries on the client side." I don't see why virtual memory is particularly relevant here. ---Now is just "Java interpreter executes ...". Section 1.2, paragraph 2 Same para: "Based on these premise [...]" Should be "premises". ---DONE Section 6, 1st paragraph: "Visper, provides [...]" Omit the comma, ",". ---DONE What do the initials RT stand for? ---Section 2, 3rd paragraph