Two popular approaches for compiling Java programs are Just-In-Time (JIT) compilation (e.g. Sun Hotspot [29], Cacao [18], OpenJIT [24], shuJIT [28], vanilla Jalapeno [1]) and static compilation (e.g. BulletTrain [22], Excelsior JET [10], GCJ [32], IBM VisualAge for Java [14], JOVE [15]). It would be wrong to say one approach is definitely better than the other, since they are suited for different situations [7]. In fact, current research on ``quasi-static compilation'' [27] shows that combining these two may yield excellent results.
In practice, static Java compilers are sometimes desirable over JIT compilers because they have many advantages [3,5,7]:
Static compilation yields more robust deployed applications. On the one hand, a deployment JIT may be different from the development JIT, which can cause problems due to even slight differences in the virtual machine or library code. With static compilation, programs are compiled into native code allowing the developer to test exactly what is deployed. On the other hand, compilers have bugs. Crashes caused by static compiler bugs sometimes happen at compile time (unless the bug is the kind that generates bad code silently), while bugs in the JIT may cause crashes at program execution time, and some of them may only surface after a portion of the program has been executed many times. Moreover, if the program crashes due to a bug in either the compiler or the program itself, statically compiled code is much easier to debug because the run-time trace is more predictable.
Static compilation provides better intellectual property protection. Native code is much harder to reverse-engineer than Java bytecode.
Static Java compilers can perform resource intensive optimization before the execution of the program. In contrast, JIT compilers must perform analysis at execution time, thus are limited to simple optimizations that can be done without a large impact on the combined compile and execute time.
Static compilation achieves greatly reduced start-up cost, reduced memory usage, automatic sharing of code by the OS between applications, and easier linking with native code.
Last but not least, static compilation is better suited for code certification than JIT compilation. It is significantly easier to achieve higher safety assurance by removing the compiler from the trusted computing base. There has been a lot of work done in this area [23,21,19] which mostly focuses on static compilation.
Regardless of the above advantages, there is an ongoing debate in the Java community on whether statically compiled implementations can meet the Java specification on dynamic features such as binary compatibility. Our paper presents a scheme that accommodates the seemingly contradictory goal of full Java compliance and static compilation, thus showing that binary compatibility can indeed be supported using static compilers. Following the inspiration of ``quasi-static compilation'' [27], this technique in practice can also be used together with other JIT compilation techniques to achieve an optimal balance point between static and dynamic compilation. Thus we believe this result is of interest to the general audience in the JVM community.
