Real-time Java, part 2nd

The performance of Java applications is often a hot topic in the development community. Because the language was designed to support the application's portability goals in an interpreted way, the performance levels provided by the early Java runtime were much lower than those compiled languages such as C and C + +. Although these languages can provide higher performance, the generated code can only be performed on a limited number of systems. Over the past decade, Java runtime vendors have developed complex dynamic compilers, often called just-in-time (Just-in-time,jit) compilers. When the program is running, the JIT compiler chooses to compile the cost code for the most frequently executed method. Running the local code instead of compiling it before the program runs (a program written in C or C + + is exactly the latter case) ensures portability needs. Some JIT compilers can compile all code without even using an interpreter, but these compilers still keep the portability of Java applications by doing something while the program is executing.

Due to the many improvements in dynamic compilation technology, in many applications, modern JIT compilers can produce application performance comparable to static compilation of C or C + +. However, there are still many software developers who believe that dynamic compilation, based on experience or hearsay, can severely disrupt program operations because the compiler must share the CPU with the application. Some developers strongly call for static compilation of Java code and are convinced that it solves performance problems. This view is correct for some applications and execution environments, and static compilation can greatly improve Java performance, or it is the only practical choice. However, the static compilation of Java applications has also created a lot of complexity while gaining high performance. A typical Java developer may not fully appreciate the advantages of a JIT dynamic compiler.

This paper examines some of the problems involved in the static compilation and dynamic compilation of the Java language, focusing on the real-time (RT) system. This paper briefly describes the operating principles of the Java language interpreter and explains the advantages and disadvantages of the modern JIT compiler performing native code compilation. Describes the AOT compilation technology that IBM® publishes in Websphere®real time and some of its pros and cons. The two compilation strategies are then compared and several application areas and execution environments that are more appropriate for AOT compilation are identified. The point is that these two compilation techniques are not mutually exclusive: Even in the various applications that are most effective with both technologies, they have some advantages and disadvantages that affect the application, respectively.

Executing Java programs

Java programs are originally compiled in a platform-independent format (class files) that are cost-neutral via the Java SDK's Javac program. You can consider this format as a Java platform because it defines all the information that is required to execute a Java program. The Java program execution engine, also known as the Java Runtime Environment (JRE), contains virtual machines that implement the Java platform for specific local platforms. For example, the IBM system p™ platform running on the linux® Intel x86 platform, the Sun Solaris platform, and the aix® operating system has a JRE on each platform. These JRE implementations implement all local support so that programs written for the Java platform can be properly executed.

An important part of the Java Platform Program representation is the byte code sequence, which describes the operations performed by each method in the Java class. The bytecode uses a theoretically infinite operand stack to describe the calculation. This stack based program representation provides platform independence because it does not rely on the number of registers available on any particular local platform's CPU. The operations that can be performed on the operand stack are defined independently of the instruction set of all local processors. The Java virtual machine (JVM) specification defines the execution of these bytecode (see Resources). When executing a Java program, any JRE used for any particular local platform must comply with the rules listed in the JVM specification.

Because the stack-based local platform is rare (the Intel X87 floating-point coprocessor is an obvious exception), most local platforms cannot execute Java bytecode directly. To solve this problem, the early JRE executes Java programs by interpreting bytecode. That is, the JVM repeats itself in one loop:

Gets the next byte code to be executed.

Decoding.

Gets the required number of operands from the operand stack.

Perform actions according to the JVM specification.

Writes the result back to the stack.

The advantage of this approach is its simplicity: the JRE developer simply writes code to process each byte code. And because less than 255 bytecode is used to describe operations, the cost of implementation is lower. The downside, of course, is performance: This is an early problem that has caused many people to be dissatisfied with the Java platform, albeit with many other advantages.

Resolving the performance gap between languages such as C or C + + means that local code compilation for the Java platform is developed using a way that does not compromise portability.