JIT stands for Just-In-Time Compiler.
It’s part of the JVM’s execution engine that:
- Translates bytecode into native machine code
- Does it at runtime, not before (like C compilers do)
🔸 Why JIT?
-
The default JVM interpreter reads bytecode line-by-line → this is portable but slow.
-
JIT watches which methods run frequently (hot paths) → compiles them into native CPU instructions
-
Native code runs much faster than interpreted bytecode.
✅ JIT = runtime performance boost without losing portability
🔹 How JIT Works (Step-by-Step)
-
You run your Java app
-
JVM starts executing with an interpreter
-
JVM uses profiling to monitor which methods are called often
-
Once a method is called enough times (e.g., 10,000), it becomes “hot”
-
JIT kicks in:
-
Compiles that method’s bytecode to native machine code
-
Stores the compiled version in memory
-
-
Next time the method runs → JVM uses the native version directly
🔸 Example
for (int i = 0; i < 1_000_000; i++) {
doSomething(); // Hot method
}-
After a few thousand iterations,
doSomething()becomes “hot” -
JIT compiles it → from bytecode to machine code
-
From then on, it runs much faster
🔹 Types of JIT in HotSpot JVM
| JIT Compiler | Description |
|---|---|
| C1 (Client Compiler) | Fast startup, basic optimizations (used in GUI apps) |
| C2 (Server Compiler) | Aggressive optimizations, used for long-running apps like servers |
| Tiered Compilation | Combines C1 and C2 for best of both worlds (enabled by default since Java 8) |
🔧 Optimizations JIT Can Do
-
Method inlining
-
Loop unrolling
-
Dead code elimination
-
Escape analysis (stack allocation vs heap)
-
Constant folding
These are similar to what C/C++ compilers do, but at runtime, with real profiling data.
✅ TL;DR
The JIT compiler in Java converts frequently-used bytecode into native code at runtime, improving performance while keeping Java portable and dynamic.
Let me know if you want to see JIT tuning options, diagnostic flags, or how to inspect JIT behavior using tools like -XX:+PrintCompilation.