In the Java programming language and environment, a just-in-time (JIT) compiler is a program that turns Javabytecode (a program that contains instructions that must be interpreted) into instructions that can be sent directly to theprocessor. After you've written a Java program, the source language statements are compiled by the Javacompiler into bytecode rather than into code that contains instructions that match a particular hardware platform's processor (for example, an IntelPentium microprocessor or an IBM System/390 processor). The bytecode is platform-independent code that can be sent to any platform and run on that platform.
In the past, most programs written in any language have had to be recompiled, and sometimes, rewritten for each computer platform. One of the biggest advantages of Java is that you only have to write and compile a program once. The Java on any platform will interpret the compiled bytecode into instructions understandable by the particular processor. However, the virtual machine handles one bytecode instruction at a time. Using the Java just-in-time compiler (really a second compiler) at the particular system platform compiles the bytecode into the particular system code (as though the program had been compiled initially on that platform). Once the code has been(re-)compiled by the JIT compiler, it will usually run more quickly in the computer.
The just-in-time compiler comes with the virtual machine and is used optionally. It compiles the bytecode into platform-specific executable code that is immediately executed. Sun Microsystems suggests that it's usually faster to select the JIT compiler option, especially if the method executable is repeatedly reused.
The Just In Time Compiler (JIT) concept and more generally adaptive optimization is well known concept in many languages besides Java (.Net, Lua, JRuby).
In order to explain what is JIT Compiler I want to start with a definition of compiler concept. According to wikipedia compiler is "a computer program that transforms the source language into another computer language (the target language)".
We are all familiar with static java compiler (javac) that compiles human readable .java files to a byte code that can be interpreted by JVM - .class files. Then what does JIT compile? The answer will given a moment later after explanation of what is "Just in Time".
According to most researches, 80% of execution time is spent in executing 20% of code. That would be great if there was a way to determine those 20% of code and to optimize them. That's exactly what JIT does - during runtime it gathers statistics, finds the "hot" code compiles it from JVM interpreted bytecode (that is stored in .class files) to a native code that is executed directly by Operating System and heavily optimizes it. Smallest compilation unit is single method. Compilation and statistics gathering is done in parallel to program execution by special threads. During statistics gathering the compiler makes hypotheses about code function and as the time passes tries to prove or to disprove them. If the hypothesis is dis-proven the code is deoptimized and recompiled again.
The name "Hotspot" of Sun (Oracle) JVM is chosen because of the ability of this Virtual Machine to find "hot" spots in code.
What optimizations does JIT?
Let's look closely at more optimizations done by JIT.
- Inline methods - instead of calling method on an instance of the object it copies the method to caller code. The hot methods should be located as close to the caller as possible to prevent any overhead.
- Eliminate locks if monitor is not reachable from other threads
- Replace interface with direct method calls for method implemented only once to eliminate calling of virtual functions overhead
- Join adjacent synchronized blocks on the same object
- Eliminate dead code
- Drop memory write for non-volatile variables
- Remove prechecking NullPointerException and IndexOutOfBoundsException
- Et cetera
First of all to disable JIT Djava.compiler=NONE parameter can be used.
There are 2 types of JIT compilers in Hotspot - one is used for client program and one for server (-server option in VM parameters). Program, running on server enjoys usually from more resources than program running on client and to server program top throughput is usually more important. Hence JIT in server is more resource consuming and gathering statistics takes more time to make the statistics more accurate. For client program gathering statics for a method lasts 1500 method calls, for server 15000. These default values can be changed by -XX:CompileThreshold=XXX VM parameter.
In order to find out whether default value is good for you try enabling "XX:+PrintCompilation" and "-XX:-CITime" parameters that print JIT statistics and time CPU spent by JIT.
Benchmarks
Most of the benchmarks show that JITed code runs 10 to 20 times faster than interpreted code. There are many benchmarks done. Below given result graphs of two of them:
Its worth to mention that programs that run in JIT mode, but are still in "learning mode" run much slower than non JITed programs.
Drawbacks of JIT
JIT Increases level of unpredictability and complexity in Java program. It adds another layer that developers don't really understand. Example of possible bugs - 'happens before relations" in concurrency. JIT can easily reorder code if the change is safe for a program running in single thread. To solve this problem developers make hints to JIT using "synchronized" word or explicit locking.
Increases non heap memory footprint - JITed code is stored in "Code Cache" generation.
Advanced JIT
JIT and garbage collection.
- For GC to occur program must reach safe points. For this purpose JIT injects yieldpoints at regular intervals in native code.
- In addition to scanning of stack to find root references, registers must be scanned as they may hold objects created by JIT
Comments are appresiated.