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: C435 JGSI Review

1.  Overall
********
An interesting and well-written article on adding annotation to Java
bytecode to improve JIT performance.  The motivations for annotation
(performance with backward compatibility) are given clearly.  The
annotation scheme presented seems feasible, being reasonable in scope
with easily documented payback.  Illustrations of the "virtual register"
annotation are quite good, but the proposed annotations for "remove if
physical", "swap" and "copy" lack clear illustrations.

2.  Comments for Author(s)
*********************
Great writing overall.  The clarity falls off a bit in section 7 -- I
think clearer illustrations of what's going on in the VR location table
would help.  Consider the second to last sentence of the second
paragraph on page 15, starting "However, we can improve this code by
annotating to goto bytecode at PC 30..."  I don't see anything happening
at PC 30.  Is there meant to be an illustration here?  Did I miss it?
Or is it missing?
The next paragraph, by the way, is great.

Regarding the third paragraph on page 17, beginning "Another JVM
developed in a commercial environment is one at IBM Tokyo..."  Rather
than say "We prove this assertion false..." it would be more correct to
say "We prove this statement to be limited to non-annotation-aware JITs"

3.  Comments for Editor(s)
********************
None.

Referee 2 ****************************************************************
Subject: C435 JGSI Review


Paper: C435
Title: Annotating Java Class files with Virtual Registers for Performance
Authors: Joel Jones and Samuel Kamin

Overall recommendation: The paper raising an interesting issue but doesn't
answer any of the important questions about it. Weak recommendation
against publication.

The authors describe techniques for annotating class files with additional
information to assist in performing register allocation when methods are
compiled to native code.

The basic problem is that the paper doesn't address the difficult
and important topics associated with this issue.

The empirical results in the paper show that using annotations, it is
possible to perform better global register allocation than the very weak
local register allocation performed by kaffe. That was never in question,
and all commercial JIT's that I know of do better register allocation
than kaffe. The interesting issues are:

* Compare two methods for generating code:

        1) Generate native code using a good register allocation
        algorithm at JIT time.

        2) Generate native code using the same good register allocation
        algorithm, but assisted by class annotations.

  What takes longer? Generating code directly (method 1), or downloading
  and verifying the class annotations and then generating code using
  the annotations (method 2)?

* How much do you lose by trying to do machine independent register
  allocation? Different targets have widely varying number of registers,
  and some machines have constraints on which registers can be used for
  which operations.  All of the results in the paper are for Sparcs.
  What about IA-32?

* Many high performance JIT's do massive amounts of inlining. Is information
  like this useful in such a context? The people I talked to on the HotSpot
  project thought that such information would be useless for them.

* How many of the problems that the author's raise could be addressed
  by bytecode optimization and transformation? For example, in Figure 11,
  bytecode optimization could delay the initialization of sum2 and
  allow sum1 and sum2 to share the same local. The standard bytecode
  generated by javac is completely unoptimized. But there isn't any reason
  why we can't optimize it.
  
  Referee 3 **************************************************************
Subject: JGSI Review C435

I do not recommend this paper will be acceptable.

 1) INSIGHT:
The paper describes verifiable and machine-independent annotations to
improve register allocation. The annotation is generated off-line using
graph coloring.

 2) INTEREST:
How to generate machine-independent annotation without a number of physical
registers.

 3) NOVELTY:
To reduce code generation time at runtime, the author apply register
allocation off-line machine-independentlly. To be simple and verifiable,
some optimizations are restricted.

 4) SOUNDNESS:
Since the paper does not have detailed descriptions of key algorithms in
section 5, it is difficult to be confident about soundness.

 5) TECHNIQUE:
The annotation is simple, verifiable and corresponding to each byte code.
The correspondence does not allow a compiler to apply optimizations with
transformations of byte code.

 6) PRESENTATION:
The presentation is not structed well.
Section 4 is too long and hard to understand.

The good examples may be needed in each section to explain your techniques.

 7) COMMENTS:
In Figure 2, a code generation routine without VR can generate the same
quarity code. So, it is not suitable for motivating example.

The restriction that every VR is monotyped is too strict in practical.

Section 5 is main contribution in the paper. I recommend it should be
explained in detail. Section 7.2 "swap" annotation is also important. It
must be explained in section 5.