Hi Kazuyuki,
I guess that the reason why Jikes RVM does not have an interpreter is
mainly its implementation language Java, not for performance:
Not really. JRocket makes the same choice.
One argument is that it is simpler to have a compile-only infrastructure
rather than one that can deal with both compiled execution and
interpretation. If the cost & performance of baseline compilation is
comparable to interpretation then the advantage of a single mode of
execution could be worthwhile.
Imagine us implementing an interpreter in Java language. We need
another Java runtime to execute the interpreter, otherwise the
interpreter has been compiled into native code. A Java runtime should
be self-containing (except bootstrapping) and then the interpreter has
to be compiled. We have to implement a compiler in advance of an
interpreter.
Can we use a pre-existing AOT compiler like GCJ to compile our
interpreter? It will be difficult because compiled code has to be
compliant with the internal structure (e.g. execution engine
interface) of targetted Java runtime and other AOT compilers do not
comply with it.
On a platform for which we support optimized compilation, say IA32, then
of course we have our own compiler with which we can compile the
interpreter. On a more obscure platform for which Harmony does not have
an optimizing compiler, then this presents a problem.
I see at least three solutions to this problem:
1. Write the interpreter in C and depend on gcc's portability.
2. Write the interpreter in Java and depend on gcj's portability.
3. Leverage gcc or gcj to automatically build a (non-optimizing)
compiler back end, and then use that.
Step 3 is an adaptation of the approach used by Gregg and Ertl for their
portable forth VM. This appeals to me.
--Steve
