Subject: Re: Reviewing Java Grande Special Issue Resent-Date: Thu, 30 Sep 1999 23:18:43 -0400 Resent-From: Geoffrey Fox Resent-To: p_gcf@npac.syr.edu Date: Sun, 19 Sep 1999 14:27:19 -0400 (EDT) From: Cheng Zhong Xu To: gcf@npac.syr.edu Dear Prof. Fox, Attached are our review comments on the papers: C431, C442, C443. Please feel free to let us know if further information is needed. best regards -------------------------------------------------------------- | Cheng-Zhong Xu, Assistant Professor | | | | Wayne State University Phone: (313) 577-3856 | | Dept. of Electr. & Computer Engg. Fax: (313) 577-1101 | | Detroit, MI 48202 czxu@ece.eng.wayne.edu | | USA http://www.pdcl.eng.wayne.edu/~czxu | -------------------------------------------------------------- --------------------------------------------------------------------- C431: Ajentx: Towards an Envionrnment ... Izatt, et al This paper presents an Ajents system to support Java-compliant parallel, distributed, and mobile applications. The Ajents is essentially a communication infrastructure in support of remote object creation, remote classloading, asynchronous RMI, and object migration. While they are all important, the four features seem nothing new and their implementations are actually demonstrations of Java's RMI and object serialization facilities in some tutorials. Unfortunately, the paper presents no more or deeper information than the tutorials. For example, -- remote object creation is commonplace in any Java-based agent systems. JavaWorld has a tutorial (December 1997) about how to implement it. -- Voyage on-line document has a case study and coverage about object migration based on checkpointing and rollback. -- RMI provides direct support for asynchronous RMI; JavaWorld (December 1998) has an illustration of this. An early coverage about this should be in its tutorial column around 1997. -- Remote classloading based on JAR is also available from Sun's Java tutorial document. The paper presents some experimental results about each individual feature. However, it lacks experiments to show the overall performance of the Ajents. The matrix multiplication is too trivial to show any thing about Ajents' features in support of parallel, distributed, and mobile applications. --------------------------------------------------------------------- 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. --------------------------------------------------------------------- C442: The Java Memory Model is Fatally Flawed The paper reveals a number of problems with the Java memory model. I appreciate very much author's insights into the issue. My only concern is with its presentation. Since it is being considered for journal publication, I would suggest the author present the idea in a self-contained way and refer to publications, instead of to informal conversations, as motivations. In paragraph 1 of Page 1, the author mentioned "Guy Steele was unaware that ... but after several days of discussions at OOPSLA98 agrees that it does". Since there's are no written record about this, it may not be a fair treatment. At least to some readers like me, this may not be good way to motivate the work. In paragraph 1 of Page 3, the author said: "In talking with a number of people at OOPSLA98, I found that most people were not aware of the implications for compilers of Coherence in the JMM". I cann't understand the point either. Originality, I believe, is what all research should have.