C413 Comments Paper will be accepted in spite of third referee Referee 1 ************************************************************** Paper number: C413 Title: Locality optimization in JavaParty by means of static type analysis Authors: Michael Philippsen and Bernhard Haumacher Overall comments: This is an excellent paper, very well-written, and quite detailed. I don't have any comments which suggest ommissions or modifications to the existing work. However, I am sure that the type-analysis optimizer has come some way since the EuroPar workshop in 1998, and would like to see a new section added to the end of the paper discussing current status, implementation details, and performance. This paper sets the stage by describing in detail the algorithms used and the basic technique for cloning methods, however, it does not adequately cover the myriad implementation details which are so vital for this approach to be incorporated into the JavaParty system as described. Performance is a serious concern. Considering that cloning methods requires the addition of new parameters and a lookup table per method, I am curious as to what the overhead of this approach is (both in terms of CPU time as well as memory usage). I am also interested in whether the authors have considered compiler optimizations for this approach -- i.e. whether the standard JIT compilers could be extended to understand this lookup table and generate efficient code for it. Benchmark results would be another important addition to this paper. I would like to see some simple concurrent applications and how well they perform with and without this type-inference optimization. While it is clear that this kind of optimization has the potential to improve concurrent performance in the kind of applications which JavaParty targets, it is important to evaluate the bottom line to see if this was a success! Apart from some additional discussion of results and performance numbers, I have no other suggestions for improvement! Referee 2 *************************************************************** C413: Locality optimization in JavaParty by means of static type analysis a) Overall Recommendation ====================== A good paper, and well written. b) Words suitable for authors ========================== 1. The paper is motivated by looking at `data' locality with reference to computation -- as in paragraph 1 of the introduction section. However, the emphasis in the paper seems to be on improving performance in an application by looking at dependencies in method calls. Perhaps, an alternative motivation for introducing the paper? Also see (3) below. 2. The distinction between static and migratable objects is used in the last paragraph of page 1, and first paragraph of page 2, there is then a sudden transition into object type information. How does type analysis influence migration is not clearly mentioned in the introduction. There should, perhaps, be a bridging paragragh that links the concept of object migration with type analysis? 3. From point (1) above, on page 3 (section 2.3), the cost for co-location vs migration is derived -- however, this is based purely on the time to perform an activity `t' and the cost of communication. However, what happens if you are operating on large data sets? Migrating large amounts of data over a network has its own problems -- and these are not considered. Therefore, I think that the motivation of the paper should be changed in the introduction section. Can the cost of data migration also be factored into migrating an object? Just a suggestion. 4. There is no place in the paper where the cost and overhead of cloning is mentioned. What impact does this have. There must be significant memory overheads, for instance, in recursive calls. How are these handled? Can memory constraints not limit object migration also? How are these to be factored into the cost model that is identified in section 2.3? 5. Just a question -- can the techniques outlined in this paper also not be used to calculate upper bounds? If type information can be somehow be arranged in terms of cost, can this technique also not help in calculating bounds -- which may be needed in certain applications? 6. Section 4 -- spelling mistake maybe? new MyThreaad() ... should read new MyThread() similarly for section 4.1, second column, top of page. 7. Similar to point (4), and from section 5.1, what is the additional cost of constructing these look up tables? 8. I think the cost function is rather simplistic -- so I am not sure how useful it has actually been to determine whether migration is good or bad. 9. Performance results are sketchy. Benchmark is not identified. 10. Is reference [13] correct? Either Massachussets OR London is superfluous? Don't you only quote one? Referee 3 *************************************************************** 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".