harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sh...@computer.org
Subject Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Date Fri, 20 May 2005 02:26:01 GMT
> The problem of Java written JVM/JIT isn't one of performance.  You can
> theoretically achieve the same performance (although I'm not 100%
> convinced, I'm partially there)

It is reasonable to model the performance of a Java runtime in several
aspects, especially throughput and interactivity (start-up time).
JIT (and JVM) written in Java can achieve the same throughput as one
written in C/C++/etc. But good start-up time / interactivity are more
difficult to achieve and have to be elaborated.

Part of a runtime written in Java has to be interpreted, or compiled
before executed. Throughput is sacrificed when interpreted and
interactivity is sacrificed when compiled.

Another possible disadvantage, which might not be discussed, is
reflective nature of Java-written JVM. This has been appealed as one of
strong points in this list so far as removing boundary of
languages. But we have to consider maintenance and debugging of the runtime.
Java-written JIT is compiled by itself eventually. In the case,
debugging will become pretty hard. Of course, such a runtime will have
another interpreter or a baseline compiler (written in C/C++?) and
Java-written JIT can be debugged exhaustively. But such a reflective
nature certainly makee debugging harder.

I myself do not have any experience on development of Java-written JIT
and then I am not very sure how it makes maintainance and debugging
harder. There have been a few Java-written JIT, Jikes RVM and OpenJIT
and we may be able to have input from the developers of them if we hope.

  Kazuyuki Shudo	shudo@computer.org	http://www.shudo.net/

Mime
View raw message