Java code's lifecycle : Everything you should know

Before start reading this tutorial I would suggest to visit my earlier blog Deep Dive Into First Java Code (click here to visit) where I explained basics of first Java code in detail.

In this blog I will tell you what happens behind the scene in memory when we execute java code.

 Above dig. shows life cycle of  Java code. It is mainly divided into 2 phases:

     1. Compile time

     2. Run time

Must Read : Simple real world case study at the end of tutorial, you will never forget these concepts again.

A. Compile Time

• It is a phase when we execute Javac command.

• Compiler converts java code into byte code which independent of machine.

B. Run Time

• ClassLoader

• In a JVM, each and every class is loaded by some instance of a java.lang.ClassLoader. Developers can subclass it to add their own functionality to class loading.

• Whenever a new JVM is started by executing command java MyFirstCode, the bootstrap class loader loads Java classes into memory first. The runtime classes are packaged into JRE\lib\rt.jar. As it is a native implementation JVMs behavior of the class loader will differ.

• Bytecode Verifier 

• If we give a look at the Java Language Environment white paper by James Gosling, it says that:

“The bytecode verifier traverses the bytecodes, constructs the type state information, and verifies the types of the parameters to all the bytecode instructions. The bytecode verifier acts as a sort of gatekeeper: it ensures that code passed to the Java interpreter is in a fit state to be executed and can run without fear of breaking the Java interpreter. ”

• Interpreter 

• Once, Bytecode is verified, then it is interpreted or JIT-compiled for the native machine.
• Interpreter reads bytecode stream and converts into machine instructions. 
• These instructions are forwarded to OS.
• OS kernel further executes them on hardware.

•  Just-In-Time Compiler
• For us, it is easy to understand our native language than globally accepted languages like English, French or German.
• Same with Java, to make java code machine independent it is translated into globally accepted format i.e. bytecode.
• But what if Linux have a native instruction which results exactly similar to machine instruction generated by interpreter, and better in performance.
• Then we all will agree that, costly instruction generated by interpreter should be replaced by cheaper native instruction
• This gave rise to concept of Just-In-Time compiler. The JIT analyzes the behavior of a program while it runs and looks for opportunities to optimize the bytecode and re-compile it to machine code using the most appropriate native instruction.

Do You Know

JIT is enabled by default in JVM. It can be disabled if required but it will slow down program execution. In my next to upcoming blog I will discuss how to disable and re-enable JIT compiler.

•  How does JIT works?
• JVM is different for every platform. In simple words, it varies according to OS and internal hardware setup (eg. 32 bit/64 bit).
  
  

• In JVM, JIT compilers are supplied as standalone platform-dependent native libraries.

• If the JIT Compiler library exists, the JVM initializes Java Native Interface (JNI) native code hooks to call JIT functions available in that library instead of the equivalent function in the interpreter.

• When code becomes JIT compiled code?
• When a method is called the first time the JIT compiler compiles the method block into native code.

• This native code stored that in the code block for that method.

Do You Know

·         Interpreter: Takes only one instruction at a time for execution.  ·         Just-in-time: Takes a block of code at once and compile it before execute. so has plenty room for optimization.

Now you got idea of compiler, JIT compiler and interpreter. Lets have a look at an real world example so that you will never forget these concepts.

Real World Example

Let's say that you are trying to ask everyone in Mexico "Hello. How are you?" (Your source language) Of course, you'll first need to translate it to Spanish (the native language of the country). That translation would be "Hola. Como estas?" If you know Spanish, there would be no need for you to translate (native code / assembler). You just ask "Hola. Como estas?" If you don't know Spanish, there are 3 ways to deal with it. The first is to get a Spanish Dictionary (a compiler) and look up what the Spanish words are before you go. Perhaps you realize that "Hola. Que tal?" is one syllable shorter (compiler optimization) and use that instead. This is language compilation; you are converting the information to the native language beforehand. The second is where you look up the words in the Spanish Dictionary while you are standing in front of the first person and then store the result (looking up the words just-in-time). The advantage here is that you could get a Mandarin Dictionary and then do the same experiment in China without having to keep ten sticky notes (binaries for different platforms) of translated phrases. The third is where you look up the words while you are standing in front of each person. In essence, you interpret the words for each person separately (you act as an interpreter). The advantage here is that any changes are instantly reflected with the next person (you could change to asking "Hello. What color is your dog?" without having to fly home and restart - you don't need to recompile the phrases).