> 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 [EMAIL PROTECTED] http://www.shudo.net/
