HotSpot JVM - Why its called HotSpot

Sun/Oracle version of JVM is known as HotSpot JVM. Let’s try to understand why it’s named HotSpot  JVM which will also help us to understand what a JIT compiler is and how the execution happens from .java file upto the execution of the code.

When we compile a .java file using the javac compiler the .java file gets converted to .class file which is the Bytecode representation of the .java file. The javac compiler doesn’t directly convert the java code into the machine language instead it converts it to the Bytecode that the JVM understands. Since java Bytecode has no platform dependent code, it is executable on any hardware where the JVM has been installed even with different CPU and OS from which the code was compiled. And this is what gives java platform independence. The .class file is a binary representation of the java code which can not be understood by human and which only the JVM undserstands. This .class file is loaded in the JVM memory via class loader and is executed by the execution engine. As the Bytecode is not the machine level representation of the code,therefore, the execution engine must change the bytecode to the language that can be executed by the machine in the JVM. The bytecode can be changed to the suitable language in one of two ways.

·       Interpreter: Reads, interprets and executes the bytecode instructions one by one. As it interprets and executes instructions one by one, it can quickly interpret one bytecode, but slowly executes the interpreted result. This is the disadvantage of the interpret language. The 'language' called Bytecode basically runs like an interpreter.

·  JIT (Just-In-Time) compiler: The JIT compiler has been introduced to compensate for the disadvantages of the interpreter. The execution engine runs as an interpreter first, and at the appropriate time, the JIT compiler compiles the entire bytecode to change it to native code. After that, the execution engine no longer interprets the method, but directly executes using native code. Execution in native code is much faster than interpreting instructions one by one. The compiled code can be executed quickly since the native code is stored in the cache. 

However, it takes more time for JIT compiler to compile the code than for the interpreter to interpret the code one by one. Therefore, if the code is to be executed just once, it is better to interpret it instead of compiling. Therefore, the JVMs that use the JIT compiler internally check how frequently the method is executed and compile the method only when the frequency is higher than a certain level. So the piece or spot of code that gets executed repeatedly becomes hotter with every execution and once the certain threshold value is reached the JIT compiler compiles that portion or spot of code and keeps it in cache from where it can be directly executed next time the same code is called for execution. If the spot is not the hotspot any more, the Hotspot VM removes the native code from the cache and runs in interpreter mode.  And hence it has been named as HotSpot JVM.