What exactly is the JIT compiler inside a JVM?

Question

I'm trying to understand how Java source code is executed and I'm confused as to what the JIT-compiler inside the JVM actually is. To start off let me tell you how I understand the process of going from Java source code to executing machine code on a computer. Perhaps, I'm misunderstanding something in the process that is causing the confusion.

The steps:

1. The source code is compiled into bytecode (.class files)
2. The class files are loaded into the JVM (which is in RAM)
3. the bytecode is verified and then processed by the JIT compiler
4. the output of the JIT compiler is machine code ready for execution

Now, according to the Wikipedia article on JVM, and more specifically the "Bytecode interpreter and just-in-time compiler" section, in order to execute Java bytecode you need an interpreter (but we have a JIT compiler).

Now here's the bit that is confusing to me. I've broken it down into quotes:

"When Java bytecode is executed by an interpreter, the execution will always be slower than the execution of the same program compiled into native machine language."

1. Since the computer can only execute machine code, and an interpreter is slower at translating the bytecode to machine code than a compiler is, why does the JVM use an interpreter and not a compiler?

2. Why do we not have another intermediate executable file generated by the JIT compiler for the CPU so it can quickly execute the instructions?

"A JIT compiler may translate Java bytecode into native machine language while executing the program. The translated parts of the program can then be executed much more quickly than they could be interpreted. This technique gets applied to those parts of a program frequently executed."

Is the JIT compiler really an interpreter that has the ability to compile frequently executed code? Are the terms compiler and interpreter wrongfully used interchangeably?

Thanks in advance.

Answer 1

JIT compiler is introduced in jdk 1.1 version..before that only interpreter was there to convert byte code to bit code as interpreter converts line by line byte to bit format this makes it slow...here JIt compiler came to optimise the performance...what JIT compiler does-> it identifies repeated instructions from the code...converts those repeatedly executable code into bit code and save it into cache memory and loads it whenever needed... for example i have for loop inside that i have written 10 lines of code and this loop is executing 100 times. if there will be only interpreter for each and every iteration it will convert those 10 lines of code from byte to bit code...and instead of that JIT compiler will convert those 10 lines into bit code and saves it into cache and loads for each iteration when needed....it means converting those 10 lines into bit code only time but using it until loop terminated....

The JIT compiler will come only whenever repeated instructions are there...so JIT compiler removes the redundunt code and optimises the performance....i hope it will help

Answer 2

Since the computer can only execute machine code, and an interpreter is slower at translating the bytecode to machine code than a compiler is, why does the JVM use an interpreter and not a compiler?

Optimized Compiling is a very long lasting process. And this expense is only justified if the program runs a longer time.

Optimizations at the wrong places are unnecessary. A piece of code that is traversed only once will consume more compile time than interpretation time, so interpretation is ok.

Both subjects are better handled by a compiler that jumps in if certain sections of the code are processed frequently.

Why do we not have another intermediate executable file generated by the JIT compiler for the CPU so it can quickly execute the instructions?

This "file" (the compiled fragments) does exist in memory. It is not serialized as file because:

• such a file would be heavily dependent on the operating system and the hardware
• there are certain code optimizations that can only be applied at runtime, e.g. the JIT-compiler can optimize virtual calls (replacing a dynmamic dispatch by a jump or even inlined code)

Is the JIT compiler really an interpreter that has the ability to compile > frequently executed code? Are the terms compiler and interpreter wrongfully used interchangeably?

While the JVM Hotspot compiler compiles frequently executed code, other JIT compilers may decide to compile depending on other heuristics. The terms "JIT compiler" and "interpreter" are not clearly distinguishable. Most interpreters optimize (compile just in time) and almost every JIT compiler interpretes.

Answer 3

Since the computer can only execute machine code, and an interpreter is slower at translating the bytecode to machine code than a compiler is, why does the JVM use an interpreter and not a compiler?

Because compiling to machine code also takes time, especially when it has to analyze the code to optimize it, so interpreting is fast enough to execute most of the time, and actually faster than compile+run if only run once/occationally.

Also, an interpreter doesn't "translating the bytecode to machine code". It evaluates the bytecode and performs the operations requested by the bytecode. The interpreter itself is machine code, but it doesn't translate bytecode, it interprets/evaluates the bytecode.

Why do we not have another intermediate executable file generated by the JIT compiler for the CPU so it can quickly execute the instructions?

That would violate the Write Once, Run Anywhere paradigm of Java.

Is the JIT compiler really an interpreter that has the ability to compile frequently executed code?

No, the JIT compiler (or more accurately, the HotSpot compiler, as mentioned by EJP) is a compiler executed by the JVM as needed.

Are the terms compiler and interpreter wrongfully used interchangeably?

Correct. They cannot be used interchangeably, since they don't do the same thing. The interpreter executes bytecode. The JIT/HotSpot compiler converts bytecode to machine code, but doesn't run it.