JVM Architecture




What is JVM ?

JVM (Java Virtual Machine) : Java was developed with the concept of WORA (Write Once Run Anywhere), which runs on a VM(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). Means The compiler compiles the Java file into a Java .class file, then that .class file is input into the JVM, which Loads and executes the class file. The JVM consists of three main components: the class loader, the runtime data area, and the execution engine.



JVM Architecture:


  • The class loader is responsible for loading classes into the JVM. When you run a Java program, the class loader searches for the necessary classes and loads them into the runtime data area.
  • The runtime data area is where the JVM stores data during program execution. It consists of several different areas, including the method area (where class and method information is stored), the heap (where objects are stored), and the stack (where method calls and local variables are stored).
  • The execution engine is responsible for executing the bytecode (compiled Java code) that is loaded into the JVM. The execution engine reads the bytecode and performs the necessary operations to carry out the program’s instructions.
The JVM also includes a garbage collector, which automatically frees up memory that is no longer being used by the program.
  • 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
  • Initilization



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 ClassLoder 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, instanceof, invokedynamic, invokeinterface, invokespecial, invokestatic, invokevirtual, ldc, ldc_w, multianewarray, 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 :

The runtime data area is the memory area where data is stored during program execution. It is divided into several different areas, each with its own purpose. Let’s take a look at an example program to understand how memory is allocated in the 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.
  • Local Variable Array – Related to the method how many local variables are involved and the corresponding values will be stored here.
  • Operand stack – If any intermediate operation is required to perform, operand stack acts as runtime workspace to perform the operation.
  • Frame data – All symbols corresponding to the method is stored here. In the case of any exception, the catch block information will be maintained in the frame data

 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. Each thread will have separate PC Registers, to hold the address of current executing instruction once the instruction is executed the PC register will be updated with the next instruction.

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.

The JIT Compiler neutralizes the disadvantage of the interpreter. The Execution Engine will be using the help of the interpreter in converting byte code, but when it finds repeated code it uses the JIT compiler, which compiles the entire bytecode and changes it to native code. This native code will be used directly for repeated method calls, which improve the performance of the system.
  • Intermediate Code generator – Produces intermediate code
  • Code Optimizer – Responsible for optimizing the intermediate code generated above
  • Target Code Generator – Responsible for Generating Machine Code or Native Code
  • Profiler – A special component, responsible for finding hotspots, i.e. whether the method is called multiple times or not.
3.3 Garbage Collector:
It destroys un-referenced objects. For more on Garbage Collector, refer Garbage Collector. Collects and removes unreferenced objects. Garbage Collection can be triggered by calling "System.gc()", but the execution is not guaranteed. Garbage collection of the JVM collects the objects that are created. 

Java Native Interface (JNI) :
JNI will be interacting with the Native Method Libraries and provides the Native Libraries required for the Execution Engine.

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.

Comments

Post a Comment