From: Rafal Lewczuk <[EMAIL PROTECTED]> > Things like ORP (and propably Jikes - not > sure) are intentionally omitting interpreter, relying on a fast, > non-optimizing JIT instead. I don't know but it may affect some design > decisions. Assuming that framework = set of interfaces (for example > GC) + set of conventions (for example, stack layout), discarding > interpreter part in a server VM may lead to more opportunities in > optimizing VM.
I guess that the reason why Jikes RVM does not have an interpreter is mainly its implementation language Java, not for performance: | Subject: Re: Other interesting papers and research | Date: Mon, 06 Jun 2005 21:34:44 +0900 (JST) | For Java-written JVM, it seems to be natural to have a baseline | compiler instead of an interpreter. | | It looks complicated to have an interpreter for a Java-written JVM. We | hope that the architecture of a JVM (e.g. interpreter or baseline | compiler) is independent of the language for implementing a certain | part of JVM. But there seems to be an implication between them. | Any comment? 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. We will first implement a baseline compiler to compile an interpreter. Do we implement an interpreter after having a baseline compiler? There needs a very strong reason to do it. And in many cases, we will not have it. This is what happend in the Jikes RVM (Jalapeno) team, I guess. If this is correct, discarding an interpreter was not for optimization and rather for its implementation language. Kazuyuki Shudo [EMAIL PROTECTED] http://www.shudo.net/
