Subject: Resent-Date: Thu, 30 Sep 1999 23:19:49 -0400 Resent-From: Geoffrey Fox Resent-To: p_gcf@npac.syr.edu Date: Tue, 21 Sep 1999 17:11:28 -0400 (EDT) From: Tim Brecht To: gcf@npac.syr.edu Subject C413 JGSI review Paper: C413 Title: Locality optimization in JavaParty by means of static type analysis Overall Recommendation: Reject This paper describes work being done on a difficult problem of automatically being able to determine where to locate execution units in a parallel or distributed computation in order to (I assume but don't believe it is stated) to reduce application execution times. The target language for this paper is Java. There seems to be some interesting ideas in this paper. However, I feel that their practicality and limitations aren't demonstrated sufficiently in this paper to warrant publication in a journal. The big motivation for this work is to improve performance and the section on performance is extremely limited (a small portion of one paragraph). When the techniques do not work results are not given so one doesn't know how poorly the program will execute when the techniques don't work. In my view probably the biggest drawback is the inability to handle what would probably be the two most typical techniques for creating parallelism: 1) creating threads in a loop (and assigning them to an array 2) using a workpile (or workcrew) Since the system currently can't handle such techniques its applicability is severely limited. A note is made that these problems will be examined in the future but little is done to make the reader feel comfortable that the problem can/will be solved. I found the big picture to be somewhat lacking. Section 6 notes the various components that have been built but in my view this paper does not adequately describe how these pieces are used together in the context of the work described. I like the reality check sections but felt that the authors failed to sufficiently explain what the implications of reality were for the system they are intending to build. The distinction between objects and activities and how these are separated was not as clear as it should be. From the example in Figure 1 it seemed that the way to locate an activity on a specific JVM/host is to locate that object on that JVM/host. E.g., if invoking a method foo (activity) on object B (object) it would seem necessary that the method can only be invoked if they are on the same node (so I don't see how they can be separated). Later in Section 2.2 a decision is to be made was to weather to locate the object and on the same or different nodes. The cost(t,a) is determined if t and a are not on the same node. Perhaps an explanation that included the use of Figure 1 to clearly show what the object being considered is and what the activity is and how they are separated would help. The discussion in Section 2.2. begins by assuming total knowledge then goes on to assume additional heuristics. I don't see why the need for additional information if you have *total* knowledge. Minor corrections: "For imperative programming languages, literature is full the --^ The sections discussing "inheritance anomaly" seems worded incorrectly. I think they should either be "the inheritance anomaly" or "inheritance anomalies". "Several suggestions have been made, e.g. [19]." The suggestions need to be explained and this is not a sentence if the reference is removed. It should read as a sentence when the reference is removed. There are other instances of sentences that aren't sentences if the reference is removed. The phrase "might run idle" => something like "may be idle".