Just-In-time compilation

In Java, we write code in .java files and are referred to as source files. Java application source files are compiled; but instead of being compiled into a specific binary for a specific CPU, they are compiled into an optimized architecture neutral assembly language know as Java bytecodes, and are saved in .class files.  These class files (Java bytecode) are then loaded and run by the Java Virtual Machine (JVM), similar to other interpreters.  Unlike other interpreters, Java can compile the bytecode again to platform specific binary with additional optimizations during execution; and this is possible as Java is executing an optimized binary, not a high level source code. Since this compilation occurs during program execution, it is called Just-In-Time compilation.

Hotspot JVM

Oracle’s standard JVM implementation (that we download from oracle downloads page) is known as Hotspot JVM. Hotspots are sections of code that are executed more than other sections of code. When the JVM executes code, it does not begin compiling the code immediately. It would not be worth to compile and execute a section of code which is executed only once or very less times; instead it would be better to interpret the bytecode directly without compiling in those cases. Compiling a frequently executing section of code (hotspot) will be worth as the extra CPU cycle time taken for compilation can be overcome during subsequent runs. Also, more the JVM executes sections of code it can figure out more optimizations that can be made.

JIT Compiler versions

There are 3 versions of the JIT compiler, and they are:

• A 32-bit client version (-client)
• A 32-bit server version (-server)
• A 64-bit server version (-d64)

To some extent, you can choose the compiler you want to use by supplying an argument to java (-client, -server or –d64). However different Java binaries (32 bit for Linux, 64 bit for Windows etc.) contain different compilers and may also different behavior for these flags. For instance,

• If you have a 64-bit Windows, 64-bit Linux or Mac OS X JVM and specify -client, -server or –d64, the application will use the 64-bit server compiler in all cases.

o   Solaris 64-bit is an exception where -client will give 32 bit client, -server will give 32 bit server and –d64 will give 64 bit server, as expected.

• If you have a 32-bit Linux, 32-bit Solaris or 32-bit Windows JVM and if you specify –client you get 32-bit client, if you specify –server you will get 32-bit server, and if you specify -d64, you will get an error that the given instance does not support a 64-bit JVM.

Now we will see differences between client and server, and then 32-bit and 64-bit.

Client, Server and Tiered JVM

A JVM does not immediately compile the bytecode to platform specific binary while executing. A hotspot JVM will find and compile hotspots and execute the rest directly from bytecode. Hotspots are sections of code that are executed more frequently than other sections. The more the JVM get time, the better hotspots it can find and hence better optimization.

The client compiler begins compiling the bytecode sooner than the server compiler does. Therefore, during the beginning of code execution, the client compiler will be faster, and in the long run, a server compiler would have saved more time, as ultimately, code produced by the server compiler will be faster than that produced by the client compiler.  

There is also another variant of compilation which is a combination of these: tiered compilation. With tiered compilation, code is first compiled by the client compiler; and later as it becomes hot, it is recompiled by the server compiler. Starting from Java 7u4, tiered compilation usually offers the best performance for an application. Still, tiered compilation has a few concerns in Java 7, and so it is not the default setting. To use tiered compilation, use the flag -XX:+TieredCompilation (the default value of which is false) along with server compiler. In Java 8, tiered compilation is enabled by default if server compiler is the default.

32-bit vs. 64-bit

For a 32-bit operating system, you can only use a 32-bit version of the JVM. For a 64-bit operating system, you can choose to use either the 32- or 64-bit version of JVM. In certain situations, like when heap space is less than 3GB and the total process space (includes the heap, permgen, native code and native memory) is less than 4 GB, then 32-bit JVM might give a better performance over the 64-bit version, because, the memory references within the 32-bit JVM will be only 32 bits, and manipulating them is less expensive than manipulating 64-bit references.

Finding your JIT versions

You can find your JIT versions as:

java –version

In my personal system this gives, below output:

java version "1.7.0_51"

Java(TM) SE Runtime Environment (build 1.7.0_51-b13)

Java HotSpot(TM) Client VM (build 24.51-b03, mixed mode, sharing)

And even check if version is changing with options as:

java –server –version

This will give the output as:

java version "1.7.0_51"

Java(TM) SE Runtime Environment (build 1.7.0_51-b13)

Java HotSpot(TM) Server VM (build 24.51-b03, mixed mode)

And if I try an invalid option (-d64 is invalid for 32-bit) as:

java –d64 –version

This will give the output as:

Error: This Java instance does not support a 64-bit JVM.

Please install the desired version.

You can play around with these options in your machine and understand better.

Reference

For further learning and examples, you can refer the book Java Performance: The Definitive Guide by Scott Oaks.