What is JVM ?

JVM (Java Virtual Machine) : It is an engine that provide runtime environment to lunch
the Java application and responsible for converting the byte code (.class file) which
generated by compiling the (.java file). JVM is a part of Java Runtime
Environment(JRE).

Java applications are called WORA (Write Once Run Anywhere). This means a
programmer can develop Java code on one system and can expect it to run on any
other Java-enabled system without any adjustment. This is all possible because of JVM.

JVM Architecture :
 JVM is divided into three main subsystems:
1. ClassLoader
2. Runtime Data Area (Memory Area)
3. Execution Engine
1. ClassLoader:
The ClassLoader is a part of the Java Runtime Environment (JRE) that dynamically
loads Java class files from file system, network or any other source into the Java
Virtual Machine. It have three main phases :

 Loading
 Linking
 Initialization

1.1 Loading :
Is the part that responsible of loading the byte code (.class file) from various resources
(e.g. file system, jar file, network socket) into memory.

The Load phase involve three different type of ClassLoader:

 Bootstrap Class Loader: It loads JDK internal classes. It loads rt.jar and other core
classes for example java.lang.* package classes.
 Extensions Class Loader: It loads classes from the JDK extensions directory, usually
$JAVA_HOME/lib/ext directory.
 Application Class Loader: It loads classes from the current classpath. We can set
classpath while invoking a program using -cp or -classpath command line option.

How ClassLoader works in Java !!

 When JVM request for a class, it invokes a loadClass() method of the
java.lang.ClassLoader class by passing the fully classified name of the class. The
loadClass() method calls for findLoadedClass() method to check that the class has
been already loaded or not. It is required to avoid loading the class multiple times.

If the class is not loaded, it delegates the request to parent ClassLoader to load the
class. If the ClassLoader is not finding the class, it invokes the findClass() method to
look for the classes in the file system. The following diagram shows how ClassLoader
loads class in Java using delegation.

Suppose that we have an application specific class Student.class. The request for
loading of this class files transfers to Application ClassLoader. It delegates to its parent
Extension ClassLoader. Further, it delegates to Bootstrap ClassLoader. Bootstrap
search that class in rt.jar and since that class is not there. Now request transfer to
Extension ClassLoader which searches for the directory jre/lib/ext and tries to locate
this class there. If the class is found there, Extension ClassLoader loads that class.
Application ClassLoader never loads that class. When the extension ClassLoader does
not load it, then Application ClaasLoader loads it from CLASSPATH in Java.

Visibility principle states that child ClassLoader can see the class loaded by the parent
ClassLoader, but vice versa is not true. It means if Application ClassLoader loads
Student.class, in such case, trying to load Student.class explicitly using Extension
ClassLoader throws java.lang.ClassNotFoundException.

1.2 Linking :
It mainly have three phases:

 Verification: It ensures the correctness of the .class file (bytecode) i.e. it checks
whether this file is properly formatted and generated by a valid compiler or not and if
that is compatible to the JVM class specification or not . If verification fails, we get run-
time exception java.lang.VerifyError. This activity is done by the component
ByteCodeVerifier. Once this activity is completed then the class file is ready for
compilation.
 Preparation: Preparation involves creating the static fields for a class or interface
and initializing such fields to their default values.This does not require the execution
of any Java Virtual Machine code; explicit initializers for static fields are executed as
part of initialization not preparation.
 Resolution: is the process of dynamically determining concrete values from symbolic
references in the run-time constant pool.

JVM Instructions
anewarray, checkcast, getfield, getstatic, instanc
eof, invokedynamic, invokeinterface, invokespeci
al, invokestatic, invokevirtual, ldc, ldc_w, multian
ewarray, new, putfield, and putstatic make
symbolic references to the run-time constant pool.
Execution of any of these instructions requires
resolution of its symbolic reference.

1.3 Initialization :
This is the final phase of Class Loading, here all static variables will be assigned with
the original values, and the static block will be executed.
 2. Runtime Data Area :
2.1 Method Area :

The Java Virtual Machine has a method area that is shared among all Java Virtual
Machine threads. The method area is analogous to the storage area for compiled code
of a conventional language or analogous to the "text" segment in an operating system
process. It stores per-class structures such as the run-time constant pool, field and
method data, and the code for methods and constructors, including the special
methods used in class and instance initialization and interface initialization.

 If memory in the method area cannot be made available to satisfy an allocation

request, the Java Virtual Machine throws an OutOfMemoryError.
2.2 Heap :

The Java Virtual Machine has a heap that is shared among all Java Virtual Machine
threads. The heap is the run-time data area from which memory for all class instances
and arrays is allocated.

The heap is created on virtual machine start-up. Heap storage for objects is reclaimed
by an automatic storage management system (known as a garbage collector); objects
are never explicitly deallocated. The Java Virtual Machine assumes no particular type
of automatic storage management system, and the storage management technique
may be chosen according to the implementor's system requirements. The heap may
be of a fixed size or may be expanded as required by the computation and may be
contracted if a larger heap becomes unnecessary. The memory for the heap does not
need to be contiguous.

A Java Virtual Machine implementation may provide the programmer or the user
control over the initial size of the heap, as well as, if the heap can be dynamically
expanded or contracted, control over the maximum and minimum heap size.

The following exceptional condition is associated with the heap:

 If a computation requires more heap than can be made available by the automatic
storage management system, the Java Virtual Machine throws an OutOfMemoryError.
2.3 Stack :

Each Java Virtual Machine thread has a private Java Virtual Machine stack, created at
the same time as the thread. A Java Virtual Machine stack stores frames . A Java
Virtual Machine stack is analogous to the stack of a conventional language such as C:
it holds local variables and partial results, and plays a part in method invocation and
return. Because the Java Virtual Machine stack is never manipulated directly except to
push and pop frames, frames may be heap allocated. The memory for a Java Virtual
Machine stack does not need to be contiguous.

In the First Edition of The Java® Virtual Machine Specification, the Java Virtual
Machine stack was known as the Java stack.

This specification permits Java Virtual Machine stacks either to be of a fixed size or to
dynamically expand and contract as required by the computation. If the Java Virtual
 Machine stacks are of a fixed size, the size of each Java Virtual Machine stack may be
chosen independently when that stack is created.

A Java Virtual Machine implementation may provide the programmer or the user
control over the initial size of Java Virtual Machine stacks, as well as, in the case of
dynamically expanding or contracting Java Virtual Machine stacks, control over the
maximum and minimum sizes.

The following exceptional conditions are associated with Java Virtual Machine stacks:

 If the computation in a thread requires a larger Java Virtual Machine stack than is
permitted, the Java Virtual Machine throws a StackOverflowError.
 If Java Virtual Machine stacks can be dynamically expanded, and expansion is
attempted but insufficient memory can be made available to effect the expansion, or
if insufficient memory can be made available to create the initial Java Virtual Machine
stack for a new thread, the Java Virtual Machine throws an OutOfMemoryError.
2.4 PC Register :

It stores the address of the of the instruction that currently executed.

2.5 Native Method Stack :

Native Method Stack holds native method information. For every thread, a separate
native method stack will be created.

3. Execution Engine :
Execution Engine handles this by executing the code present in each class.However,
before executing the program, the bytecode needs to be converted into machine
language instructions. The JVM can use an interpreter or a JIT compiler for the
execution engine.

It can be classified into three parts:

3.1 Interpreter :The interpreter reads and executes the bytecode instructions line by
line. Due to the line by line execution, the interpreter is comparatively slower.

Another disadvantage of the interpreter is that when a method is called multiple

times, every time a new interpretation is required.

3.2 Just-In-Time Compiler(JIT) : It is used to increase the efficiency of an

interpreter. It compiles the entire bytecode and changes it to native code so whenever
the interpreter sees repeated method calls, JIT provides direct native code for that
part so re-interpretation is not required, thus efficiency is improved.

3.3 Garbage Collector: It destroys un-referenced objects. For more on Garbage

Collector, refer Garbage Collector.

Java Native Interface (JNI) :

It is an interface that interacts with the Native Method Libraries and provides the
native libraries(C, C++) required for the execution. It enables JVM to call C/C++
libraries and to be called by C/C++ libraries which may be specific to hardware.

Native Method Libraries :

It is a collection of the Native Libraries(C, C++) which are required by the Execution
Engine.