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 ********************************************************** C443: Javelin++: Scalability issues in global computing Neary, et al. This paper presents an extension of Javelin in support of scalable global computing. This is a good experiment work. My major concern is its originality. As it is indicated in Section 2 that Javelin++ improved Javelin in three aspects: -- Java RMI implementation instead of TCP sockets; -- Java applications instead of applets; -- distributed broker instead of a centralized broker. While some of the extensions may not be so trivial in implementations, overall I am doubting if extensions are significant enough to justify for another journal publication. RMI provides an alternative communication mechansim to TCP. It simplifies programming, in particular, for workstealing type of parallel applications. Expectedly, RMI is slower than TCP. By how much in Javelin++? Javelin++ supports Java standalone applications, instead of Java applets. More applications can be adapted to Javelin++. The authors listed four drawbacks with Java applets. The authors are expected to show some examples in experiments that beyond the capability of Javelin. Unfortunately, the paper just simply repeats the experiment of Javelin using the same example on a cluster of PC/workstations. Javelin++ extends Javelin with distributed brokers for scalability. Associated with the distributed brokers, the paper implements a number of interesting scheduling algorithms, including work stealing for task distribution and eager scheduling for fault tolerance. With more work on the distributed scheduling strategies with some analysis of their scalability and overhead, it might be more appropriate to present the work as a scheduling paper. --------------------------------------------------------------------- Referee 2 ***************************************************************** Referee report for Javelin++ Seems like a reasonable paper, but the presentation could be cleaned up a bit. This paper describes a distributed work-stealing system, focusing mostly on two work-stealing algorithms. The introduction is rambling and repetitious, talking about a number of important issues, most of which are only touched upon in the body of the paper. This paper is about load balancing, which is fine, but you have to get pretty far through the paper to realize that the other issues are dealt with only in passing. I would rather see an introduction that says ``there are n fundamental issues, but here we focus on scalable work stealing and load balancing''. The paper would benefit from a more complete discussion of the kinds of applications Javelin++ is intended to support. The only example considered is rendering, which is the very model of an ``embarrasingly parallel'' application. I have no quarrel with this, but I think a discussion of how other kinds of applications (or even other applications) fit into their splittable interface would be helpful in understanding what this system can and can't do. Are there requirements about determinism (what happens if you do the same piece twice, perhaps as a result of fault-tolerance?). What if pieces need to share data? Can concurrent pieces communicate with one another? When loading classes dynamically, does Javelin++ ensure that all the classes needed by an application have been loaded before the computation starts? I can imagine that pausing an application in the middle to load a user-defined class could be disruptive. What was the broker structure for the test application? Are there any performance numbers for broker lookup, reconfiguration, etc? Referee 3 **************************************************************** Subject: C443 JGSI Review a) publish b) this paper describes an improved version of the Javelin system, which provides a Java-based infrastructure for global computing. The impovements include replacing low level TCP-based communication by Java RMI, replacing host applets with host applications (a host is a CPU provider), and finally introducing distributed brokers supporting at least two distinct scheduling algorithms. Going for a highier level communication protocol is definitely the right thing to do, while abandoning applets seems to me controversial. Indeed, it simplifies implementation at the cost of software installation and the idea of running the jevelin host as a screen server is cool. However, I am not convinced by the author arguments that the jevelin host cannot be run as an applet. This would require implementation of proxies for distributed brokers, as some other project do. For enabling access to the local resources, for example, a signed applet can be used. By the way, the paper does not describe the security aspects of the system. An interesting issue here is how to build trust between the host and the client, with a chain of brokers serving as the medeworkers.Finally, the idea of distributed workers is a good begining for a scalable, and fault tolerant system. The paper is nicely written, clearly describing the architecure of the system, its APIs, and scheduling mechanism, and is well illustarted with an example application and performance analysis.