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 *********************************************************** Subject: (C439) JGSI Review Papaer number: C439 Title: Extending Java Virtual Machine with Integer-Reference Conversion Authors: Yutaka Oiwa, Kenjiro Taura, Akinori Yonezawa Overall comments: This paper describes a mechanism which improves integer arithmetic performance for dynamically-typed languages (such as Scheme) which are compiled to JVM bytecodes. This is accomplished by avoiding the use of the 'Integer' reference class which has a performance penalty for boxing and unboxing its integer value. A new class, 'Descriptor', is introduced which is a superclass of java.lang.Object. Changes in the implementation of several JVM bytecodes, as well as the class verifier, are required. My first overall comment is that this paper is probably too long. The technique described here has limited use, and probably does not require 16 pages to describe; I would suggest trimming down some of the introductory material as well as the appendices. Secondly, it is unclear whether this approach can be generalized to other types (e.g., strings, floating-point numbers, etc.) The technique described here only applies to integers and seems to assume a particular data format of these objects within the JVM (i.e. 31-bit values where the LSB can be used to indicate a reference versus an unboxed primitive value). Some discussion about these issues should be added. My third concern is that this approach seems to be undermotivated. Changing the implementation of JVM bytecodes, the verifier, and adding a superclass to java.lang.Object are all very serious modifications to the Java language environment to support such a limited feature. Why would it not be possible to improve the performance of the 'Integer' class through other techniques, such as specialized compiler optimizations? It is not obvious that the use of the Integer reference type is *fundamentally* flawed in terms of performance, if the compiler is able to work around its semantic limitations. If my intuition about this is wrong, the authors should provide an explanation as to why compiler techniques alone are not sufficient. Otherwise, this paper is clearly written and presented. I do think that some of the material could be removed for the sake of space, but there are no serious structural problems with the paper. Referee 2 ****************************************************************** Subject: C439 JGSI Review Paper no. C439 Title: Extending Java Virtual Machine with Integer-Reference Conversion Reviewer: Mark Bull Overall Recommendation: Publish with minor revisions Comments to authors: An interesting and clearly presented paper. The English grammar needs some attention. section 1, para 1: Add references to Scheme and ML. section 1, para 2, line 3: could -> can section 1, para 4, line 7/8: statically typed program -> statically typed programs section 1, para 5 -> The example code for this operation is shown in Figure 2. Of the three steps, the final step is the most problematic, as it causes huge numbers of objects to be allocated throughout the execution of a typical program. Generally the ....... integer additions. Furthermore, it creates many discarded objects which have to be garbage collected, which results in frequent garbage collection. Both of these effects significantly slow down program execution. section 1, last para: add descriptions of sections 5 and 7. section 2, para 1, list item 2: bytecode -> bytecodes section 2.1, para 3, line 4: map descriptor type -> map the descriptor type section 2.1, last para, line 10: is modified -> are modified section 2.2, para 3, line 6: fit in 31 bit -> fits in 31 bits section 2.2, last para, line 1: Using static -> Using a static section 2.2, last para, last line: altering instruction set -> altering its instruction set section 2.3, line 1 after list: array -> arrays section 2.3, line 2/3 after list: as descriptor -> as a descriptor section 3, para 6, line 9: 32 bits -> 32 bit section 3, para 6, last sentence -> A malicious program might in this way access every object in the system. section 4, para 1, line 1: made experimental -> made an experimental section 4, para 4: check -> checks if argument's -> if the argument's effect for -> effect of section 4, para 5, line 1: still subset -> still a subset section 5, para 1, line 2: compiles every Scheme -> compiles Scheme section 5, para 2, line 4: 31 bit -> 31 bits section 6.2, heading: arithmetics -> arithmetic section 6.2, para 2, line 3: then -> than section 6.3 "No perfromance penalties are observed" - you should explicitly mention that performance gains are observed. section 7, para 1, line 6: introduces -> introduce section 7, para 3, line 4: has same problem -> has the same problems section 7, para 3, line 11: more generic -> a more generic Comments to referee: Referee 3 ************************************************************************ Subject: C439 JGSI Review Paper: Extending Java Virtual Machine with Interger-Reference Conversion Authors: Yutaka Oiwa, Kenjiro Taura, Akinori Yonezawa Number: C439 a)Overall Recommendation Scale used: 1(trivial) to 5(outstanding) Recommendation: 3, accept Technical Contribution: 3 Technical Content: 4 Presentation: 3 Accept it. b)Words suitable for authors I recommend acceptance. The paper is sound, has a proposal for extending Bytecode Language and JVM engines to make it more suitable to efficiently support other programming languages other than Java and it has full implementation of the proposed idea. This paper shows that although Java Bytecode language is pretty much tied to the Java programming language specification, compiling from other higher level languages to bytecode and supporting efficient mapping of these other language features on bytecode and its execution is possible. The authors show how an important language feature such as dynamic types can be supported in the Java Bytecode Language and JVM engines. 1) The authors point out that the boxed representation approach to handle dynamic types in Java has an impact in GC. This is true, but looking at the effort on optimizations based on Escape analysis (which indicates whether an object out-survives the duration of the method call that creates it), and by doing stack allocation of dynamically created objects this effect would be less important as a supporting motivation for their approach. 2) In the implementation they modified Kaffe's JIT compiler or Interpreter? I understand it was JIT compiler. How interpreted execution of these bytecode programs with the descriptor type compares with the interpreted execution of the same program versions in Scheme interpreters? Not all systems will be using JIT compilers, given its overhead and memory footprint requirements, so to support efficient interpreted execution is also important. 3) Negative point: This approach does not seem to retain compatibility with existing JVMs and tools. The class file with descriptors types would not be compiled/accepted by current JVMs implementation. So the proposed solution would imply changes on all JVMs already running. c)Words for the committee, if necessary I recommend acceptance. The paper is sound, has a proposal for extending Bytecode Language and JVM engines to make it more suitable to efficiently support other programming languages other than Java and it has full implementation of the proposed idea.