Goodbye Java Virtual Machine Migrating to a Superior Mobile-Code Alternative * Michael Franz, Wolfram Amme, and Jeffery von Ronne Department of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425, USA Abstract Despite its flaws, the Java Virtual Machine’s bytecode format (Java bytecode) is the established standard for dis- tributing mobile programs across the Internet. Any pro- posal for an alternative better mobile-code format appears doomed from the start in light of the vast amount of already existing Java bytecode. Somewhat surprisingly then, we have constructed a sys- tem architecture in which Java bytecode is supplanted by an “enhanced” alternative representation, in a manner that is completely invisible to the end-user. The substitution occurs at the web server and is provided as a value-added service. When communicating with an enhanced client computer, the enhancement-aware server will send it an enhanced class file rather than a standard Java bytecode file. Enhanced clients, on the other hand, can process both kinds of class file, but will perform better using the enhanced version. En- hanced class files are generated from standard Java byte- code as an off-line process at the server. Instead of bytecode for a virtual machine, enhanced class files contain SafeTSA, a type-safe and referentially se- cure intermediate representation based on static single as- signment form. SafeTSA is easier to verify than Java byte- code, and easier to translate into an internal representation for code optimization. The net result of this is higher code quality when used in a just-in-time compilation context in which code generation time is constrained. Our prototype implementation of an enhanced client is based on the Jalapeno Java Virtual Machine from IBM Re- search. The result of our integration is a Java runtime envi- * Effort sponsored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory (AFRL), Air Force Materiel Command, USAF, under agreement number F30602-99-1-0536. The U.S. Government is authorized to reproduce and distribute reprints for Govern- mental purposes notwithstanding any copyright annotation thereon. The Views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or en- dorsements, either expressed or implied, of DARPA, AFRL, or the U.S. Government. ronment capable of executing Java bytecode, SafeTSA, or a heterogeneous mixture of the two. The two just-in-time com- pilers share the same low-level code generator, facilitating a direct comparison of code quality. Preliminary perfor- mance results are very encouraging and show simultaneous improvements in compilation time and code quality relative to Jalapeno’s standard optimizing compiler for Java byte- code. 1 Introduction Java bytecode has become the de facto standard for trans- porting mobile code across the Internet. However, it is gen- erally acknowledged that Java bytecode is far from being an ideal mobile code representation—a considerable amount of preprocessing is required for first verifying each incom- ing class file, making sure it is safe, and the converting Java bytecode into a representation more amenable to an opti- mizing compiler. In a dynamic compilation context, this preprocessing takes place while a user is waiting. Since the patience of most users is finite, time spent on verification and repre- sentation conversion is essentially subtracted from the time available for code optimization. There are several reasons why preprocessing Java byte- code (subsequently called JVML, for Java Virtual Machine Language) for code optimization is so costly. First, the se- mantic level of JVML is significantly lower than that of source code. For example, the block structure of nested statements is lost in the transition to a linear stream of byte- code instructions and needs to be re-discovered at the code consumer’s site before any optimization algorithm can be run (Figure 1). More advanced optimizations requir far more ambitious program analyses, such as conversion to Static Single Assignment form. Second, due to the need to verify the code’s safety upon arrival at the target machine, and also due to the specific 1