This chapter covers code generation and code optimization in a JVM runtime environment, both as a general concept as well as taking a closer look at the JRockit code generation internals. We start by discussing the Java bytecode format, and how a JIT compiler works, making a case for the power of adaptive runtimes. After that, we drill down into the JRockit JVM. Finally, the reader learns how to control code generation and optimization in JRockit.
You will learn the following from this chapter:
- The benefits of a portable platform-independent language such as Java.
- The structure of the Java bytecode format and key details of the Java Virtual Machine specification.
- How the JVM interprets bytecode in order to execute a Java program.
- Adaptive optimizations at runtime versus static ahead-of-time compilation. Why the former is better but harder to do. The "gambling on performance" metaphor.
- Why code generation in an adaptive runtime is potentially very powerful.
- How Java can be compiled to native code, and what the main problems are. Where should optimizations be done—by the Java programmer, by the JVM, or at the bytecode level?
- How the JRockit code pipeline works and its design rationales.
- How to control the code generator in JRockit.
The main selling point for Java when it first came out, and the main contributor to its success as a mainstream language, was the write once/run everywhere concept. Java programs compile into platform-independent, compact Java bytecode (.class files). There is no need to recompile a Java application for different architectures, since all Java programs run on a platform-specific Java Virtual Machine that takes care of the final transition to native code.
This widely enhanced portability is a good thing. An application, such as a C++ program, that compiles to a platform-dependent format, has a lot less flexibility. The C++ compiler may compile and heavily optimize the program, for example for the x86 architecture. Then x86 will be the only architecture on which the program can run. We can't readily move the program, optimizations and all, to SPARC. It has to be recompiled, perhaps by a weaker compiler that doesn't optimize as well as for x86. Also if the x86 architecture is upgraded with new instructions, the program will not be able to take advantage of these without being recompiled. Portability can of course be achieved by distributing source code, but that may instead be subject to various license restrictions. In Java, the portability problem is moved to the JVM, and thus becomes third-party responsibility for the programmer.
In the Java world, all platforms on which a JVM exists can execute Java. Platform-independent bytecode is not a new concept per se, and has been used in several languages in the past, for example Pascal and Smalltalk. However, Java was the first language where it was a major factor in its widespread adoption.
When Java was new, its applications were mainly in the form of Applets, designed for embedded execution in a web browser. Applets are typical examples of client side programs. However, Java is not only platform-independent, but it also has several other nice intrinsic language properties such as built-in memory management and protection against buffer overruns. The JVM also provides the application with a secure sandboxed platform model. All of these things make Java ideal not only for client applications, but also for complex server side logic.
It took a few years before the benefits of Java as a server-side language were fully acknowledged. Its inherent robustness led to rapidly shorter application development times compared to C++, and to widespread server adoption. Shorter development cycles matter a lot when the application being developed is fairly complex, such as is typically the case for the server side.