harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sh...@computer.org
Subject Re: [modules] classloader/jit interface
Date Tue, 28 Jun 2005 05:19:56 GMT
From: Rafal Lewczuk <rafal.lewczuk@gmail.com>

> 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

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	shudo@computer.org	http://www.shudo.net/

View raw message