Supporting Binary Compatibility with Static Compilation£ Dachuan Yu Zhong Shao Valery Trifonov Department of Computer Science, Yale University New Haven, CT 06520-8285, U.S.A. ÝÙ¸ ×Ó¸ ØÖ ÓÒÓÚ ×ºÝк٠Abstract component. In the case of widely distributed libraries, used by many unknown applications, it is often imprac- There is an ongoing debate in the Java community on tical or impossible to recompile even only the importing whether statically compiled implementations can meet units. A popular current approach is to try to guaran- the Java specification on dynamic features such as binary tee that binaries can be directly replaced by compatible compatibility. Static compilation is sometimes desirable binaries without compromising a working system. because it provides better code optimization, smaller memory footprint, more robustness, and better intellec- Binary compatibility is a concept introduced to address tual property protection. Unfortunately, none of the ex- this problem. It was initially referred to as release-to- isting static Java compilers support binary compatibility, release binary compatibility [10], and later defined in the because it incurs unacceptable performance overhead. Java Language Specification (JLS) [11], which describes In this paper, we propose a simple yet effective solu- the changes that developers are permitted to make to a tion which handles all of the binary-compatibility cases package or to a class or interface type while preserv- specified by the Java Language Specification. Our ex- ing compatibility with existing binaries. Thus the Java perimental results using an implementation in the GNU binary compatibility prescribes conditions under which Java compiler shows that the performance penalty is on modification and recompilation of classes do not neces- average less than 2%. Besides solving the problem for sitate recompilation of other classes depending on them. static compilers, it is also possible to use this technique in JIT compilers to achieve an optimal balance point be- In the Java Virtual Machine [19], support for binary tween static and dynamic compilation. compatibility is primarily due to the use of symbolic ref- erences to look up fields and methods at run-time. How- ever, in some cases a native compiler for Java is needed 1 Introduction that compiles Java (or bytecode) programs directly into native code in the same manner as compilers for C/C++. Modern software applications are often built up by com- This ahead-of-time compilation is desirable because it bining many components. Some of these components yields better optimized code, more robust deployed ap- are shared libraries which allow multiple applications to plications, and offers better intellectual property protec- share large amounts of system software. tion [3, 5, 7]. We will elaborate on this later. Shared libraries evolve over time so that new function- Nevertheless, supporting binary compatibility with ality can be added, bugs can be fixed, algorithms and ef- ahead-of-time compilation is a hard problem because of ficiency can be improved, and deprecated functions can the seemingly contradictory requirements. When cer- be removed. Evolving or modifying these libraries can tain changes are allowed due to binary compatibility, the affect applications that depend on them, thus library evo- contents of a class cannot be completely determined un- lution may cause compatibility problems. til the class is loaded. However, ahead-of-time compilers usually generate hard-coded offsets based on the layout However, it is usually undesirable to recompile a whole information of other classes at compile time. application just to accommodate the changes in a single A well-known problem is that the standard compila- £ This work is supported in part by DARPA OASIS grant F30602- tion techniques for virtual methods in object-oriented 99-1-0519, NSF grant CCR-9901011, and NSF ITR grant CCR- 0081590. Any opinions, findings, and conclusions contained in this languages preclude binary compatibility (cf. the fragile document are those of the authors and do not reflect the views of these base class problem [12, 26]). For example, the documen- agencies. tation on binary compatibility [30] in the EPOC C++ say one approach is definitely better than the other, since System says: they are suited for different situations [7]. In fact, cur- rent research on “quasi-static compilation” [27] shows that combining these two may yield excellent results. ... virtual member functions are for life—you can’t add or remove virtual member functions, or change In practice, static Java compilers are sometimes desir- the virtuality of a function, or change their decla- able over JIT compilers because they have many advan- ration order, or even override an existing function tages [3, 5, 7]: that was previously inherited, ... ¯ Static compilation yields more robust deployed ap- For compliance with the binary-compatibility require- plications. On the one hand, a deployment JIT may ments of Java some existing native compilers solve this be different from the development JIT, which can problem by generating (at least) some of the code at run cause problems due to even slight differences in the time, which unavoidably negates some of the benefits of virtual machine or library code. With static com- pre-compilation. Other existing native compilers simply pilation, programs are compiled into native code have no support for binary compatibility, because the ob- allowing the developer to test exactly what is de- vious solutions (e.g. method lookup by name at run time) ployed. On the other hand, compilers have bugs. seem to incur high performance overhead. Crashes caused by static compiler bugs sometimes happen at compile time (unless the bug is the kind This paper presents a simple yet effective solution using that generates bad code silently), while bugs in the static compilation, which meets all Java binary compati- JIT may cause crashes at program execution time, bility requirements with little performance penalty. The and some of them may only surface after a por- contributions are: tion of the program has been executed many times. Moreover, if the program crashes due to a bug in ¯ In our solution, the compilation is fully static, either the compiler or the program itself, statically which allows the compiler to take advantage of the compiled code is much easier to debug because the well-developed static compilation techniques for run-time trace is more predictable. better code optimization. ¯ Static compilation provides better intellectual prop- ¯ Our solution covers all the cases specified in the erty protection. Native code is much harder to JLS. Different features—including methods, fields, reverse-engineer than Java bytecode. interfaces, and modifiers—are supported by the ¯ Static Java compilers can perform resource inten- same set of simple core techniques. sive optimization before the execution of the pro- ¯ Our solution also detects all binary-incompatible gram. In contrast, JIT compilers must perform changes and gracefully raise proper exceptions at analysis at execution time, thus are limited to sim- load or run time. ple optimizations that can be done without a large impact on the combined compile and execute time. ¯ Our solution is efficient. We describe an implemen- tation in the GNU Java compiler (GCJ). The perfor- ¯ Static compilation achieves greatly reduced start- mance test shows that the performance penalty of up cost, reduced memory usage, automatic sharing our new technique is on average less than 2%. of code by the OS between applications, and easier linking with native code. In the remainder of this introduction, we briefly describe ¯ Last but not least, static compilation is better suited the benefits of static compilation. for code certification than JIT compilation. It is sig- nificantly easier to achieve higher safety assurance by removing the compiler from the trusted comput- 1.1 Why Static Compilation? ing base. There has been a lot of work done in this area [23, 21, 18] which mostly focuses on static Two popular approaches for compiling Java pro- compilation. grams are Just-In-Time (JIT) compilation (e.g. Sun Hotspot [29], Cacao [17], OpenJIT [24], shuJIT [28], vanilla Jalapeno [1]) and static compilation (e.g. Bullet- Regardless of the above advantages, there is an ongoing Train [22], Excelsior JET [20], GCJ [32], IBM Visu- debate in the Java community on whether statically com- alAge for Java [13], JOVE [14]). It would be wrong to piled implementations can meet the Java specification on dynamic features such as binary compatibility. Our For optimization purposes, JIT compilers often use paper presents a scheme that accommodates the seem- guarded inlining (where the guard checks for the ob- ingly contradictory goal of full Java compliance and ject type at run-time) to handle the scenario where the static compilation, thus showing that binary compatibil- inlining is invalidated by further class loading. When ity can indeed be supported using static compilers. Fol- such a scenario occurs, run-time compilation has to be lowing the inspiration of “quasi-static compilation” [27], performed. There has been also work on techniques for this technique in practice can also be used together with inlining virtual methods more efficiently [6, 15, 25]. other JIT compilation techniques to achieve an optimal balance point between static and dynamic compilation. Typically, static compilers use global or whole-program Thus we believe this result is of interest to the general