JIT Compiler

TL;DR

• The JIT (Just-In-Time) Compiler is the heart of Java’s performance engine.
• It is located inside the JVM’s Execution Engine.
• While the JVM generally interprets bytecode line-by-line, the JIT Compiler identifies heavily used “hot” methods and dynamically compiles them into pure native machine code while the application is running, drastically speeding up execution.

Concept

Bytecode is platform-agnostic, but interpreting it line-by-line is extremely slow compared to executing raw C++ machine code.
To bridge this gap, the JVM monitors which methods are called frequently (e.g., a method inside a while(true) loop).
When a method’s execution count crosses a threshold (e.g., 10,000 times), the JVM flags it as “Hot Code”.

The JIT Compiler wakes up, takes the bytecode of that hot method, aggressively optimizes it (inlining methods, eliminating dead code), and compiles it directly into native CPU instructions (0s and 1s). The next time the application calls that method, it bypasses the interpreter completely and runs the blazingly fast machine code.

Examples

public class JitDemo {
    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        
        // The first few hundred iterations are executed slowly by the INTERPRETER.
        // Eventually, the JVM realizes this is a "Hot" loop.
        // The JIT Compiler kicks in, compiles this logic to native machine code.
        // The remaining 999 million iterations execute at native hardware speed!
        for (int i = 0; i < 1_000_000_000; i++) {
            performHeavyMath(i);
        }
        
        long end = System.currentTimeMillis();
        System.out.println("Execution time: " + (end - start) + "ms");
    }
    
    public static double performHeavyMath(int i) {
        return Math.sqrt(i) * Math.sin(i);
    }
}

Interview Questions

Q: What is “Method Inlining”?
A: It is the JIT Compiler’s most powerful optimization. If Method A calls Method B, there is CPU overhead involved in creating a new Stack Frame for Method B and jumping to a new memory address. If Method B is very small (like a standard getter public String getName() { return name; }), the JIT compiler will literally copy and paste the code from Method B directly into Method A’s compiled machine code. This completely eliminates the overhead of the method call.

Q: Why doesn’t Java just compile everything to Machine Code before running (like C++)?
A: If Java compiled everything beforehand (AOT Compaction), it would lose its “Write Once, Run Anywhere” capability because the compiled file would only work on one specific CPU architecture.
Furthermore, the JIT compiler actually has an advantage over C++ compilers: it has Runtime Profiling. The JIT knows exactly how your application behaves in real-time (e.g., it knows that an if(x > 5) branch is almost never taken) and can optimize the native code based on real-world live data, something static compilers cannot do.