Subject: (C439) JGSI Review Resent-Date: Thu, 30 Sep 1999 23:16:49 -0400 Resent-From: Geoffrey Fox Resent-To: p_gcf@npac.syr.edu Date: Sun, 12 Sep 1999 14:20:28 -0700 From: Matt Welsh To: Geoffrey Fox 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. Comments to authors: See above. Private Comments to Geoffrey Fox: This paper definitely has merit, however, the approach as described seems to have very limited applicability. It is also unclear that the authors have considered the full implications of their design, considering the complexity required, and the availability of alternative solutions to this problem. My suggestion is to reduce the length of this paper somewhat, and ask the authors to specifically address some of the questions I have above.