Subject: C439 JGSI Review
Resent-Date: Thu, 30 Sep 1999 23:18:16 -0400
Resent-From: Geoffrey Fox <gcf@npac.syr.edu>
Resent-To: p_gcf@npac.syr.edu
Date: Sat, 18 Sep 1999 20:01:49 -0700
From: Ana Velloso <aazevedo@rodan.ics.uci.edu>
To: gcf@npac.syr.edu
CC: aazevedo@rodan.ics.uci.edu

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.

--
Ana Lucia Velloso Azevedo
UC Irvine - Computer Science Department
http://www.ics.uci.edu/~aazevedo        aazevedo@ics.uci.edu
Office: (949) 824-2248                  FAX: (949) 824-4056