JavaInJava -- a Java^TM Virtual Machine Written in the Java programming lanaguage

The JavaInJava project was started in mid-October 1997 to study the feasibility of building high-quality virtual machines in the Java programming language. The main goal of the project was to investigate the suitability and scalability of the Java programming language for virtual machine implementation. More specifically, we wanted to know what kinds of issues implementing a virtual machine in the Java programming language would raise compared to building virtual machines in C or C++.

In addition to simply studying virtual machine implementation in the Java programming language, we wanted to build a clean, extensible platform for experimenting with different virtual machine implementation techniques and for building new kinds of debugging and visualization tools for programs written in the Java programming language. One potential goal was also to write a clean, "reference" Java virtual machine (JVM) implementation that would be easier to understand than virtual machines written in C or C++. At the same time we wanted to keep the back-end of the system general so that it could potentially be used for implementing back-end support for other programming languages as well.

The implementation of JavaInJava was done in a clean-room fashion without borrowing code or implementation techniques from the existing Java virtual machine implementations at Sun. In order to facilitate the understanding of the system, we tried to document most of the design decisions also at the code level. As a result, the comment/code ratio in JavaInJava source code is high (40-50% of the code are comments). Generally, since we anticipated the system to be substantially slower than normal JVM implementations, we were more concerned with clarity and style than performance.

The implementation of the basic JavaInJava system was completed by mid-December 1997. By this time, most of the design goals had been met, and the system could run simple benchmarks on different platforms. The implementation of the native function interface turned out to be more challenging than originally anticipated, and this part is still somewhat incomplete.

The first-generation JavaInJava system consists of 42 classes and approximately 10 000 lines of code of which about 40-50% are comments. The executable size is about 100 kB or 130 kB, depending on whether debugging information (line numbers, local variable information) is included in the compiled classfiles or not. The system is very slow: programs that are executed with the JavaInJava system run roughly three orders of magnitude slower than when JavaInJava is not used. For instance, the DeltaBlue benchmark executes approximately 732 times slower when run with the JavaInJava VM than when running the equivalent benchmark on Sun's Java virtual machine without JavaInJava, and in some other benchmarks the ratio is even worse. Also, we have measured that on average the underlying Java virtual machine has to execute about 540 bytecodes per each executed JavaInJava bytecode. However, quite a few of these bytecodes are used only for JavaInJava system profiling, and the performance of JavaInJava could be improved by removing these extra profiling instructions.

At the moment, the JavaInJava system is available only internally at Sun (please contact Antero Taivalsaari if interested). No decisions about possible wider distribution have been made yet. More details can be found in the technical report.