IBM i > Developer > Java

With V5R2, the JIT Compiler Comes of Age

Just-in-Time compiler support for the iSeries has been available since OS/400* V4R4. With V5R2, the JIT has reached the point where its generated code can exceed the runtime speed of code generated by the Create Java Program (CRTJVAPGM) command at the highest optimization level.

This article details some of the key areas where the JIT gained performance, such as method inlining, register allocation, model-dependent code generation and object-stack allocation. It also explains how developers can ensure that their code will compile with the JIT. Issues such as startup time versus runtime performance, options that can be used to affect the JIT for large Java* classes like JavaServer Pages* (JSPs), as well as the verification cache are also covered. For those new to the JIT compiler, weve included a glossary of terms that should help provide additional context.

Performance of User Applications
In 1998, when IBM first began converting the JIT 3.0 compiler for 32-bit AIX* to 64-bit OS/400, the compiler had a difficult time competing with the performance of more mature, static compilation on the AS/400. However, the JIT filled a gap where rapid compilation of classes was necessary for some applications. Today, with version 4.0, the JIT-generated code is typically faster than statically compiled iSeries code.

That said, it's important to note that application performance depends on many factors. Each Java application goes through the same sequence of steps during compilation, so it's important to understand what the JIT is doing to an application during those steps to allow an application to achieve improved performance.

Verification of the class file-Verification of Java classes is the process of assuring that the classes are legally constructed and adhere to all of the static rules that prevent Java programs from endangering system security or integrity. The sort of static verification thats prescribed in the Java standards allows subsequent execution to be more efficient than would be the case if security and integrity were enforced purely with runtime checks. However, this static verification can be complex and computationally expensive to perform, so  some Java implementations disable verification for trusted (and sometimes not-so-trusted) Java classes.

iSeries verification is part of static compilation, and the verification status ("valid" or "not valid") is stored with the results of the static compilation. Because the JVAPGM object that results from a static compilation is persistent and attached, as an attribute to the Java class or JAR file, verification doesn't need to be repeated each time a Java class is loaded. This improves class-loader performance (and allows iSeries Java to always verify all classes).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The JIT filled a gap where rapid compilation of classes was necessary for some applications. Today, with version 4.0, the JIT-generated code is typically faster than statically complied iSeries code.

Tweet