JVM Architecture
A Virtual Machine is a software implementation of a physical machine. Java was developed with the concept of WORA (Write Once Run Anywhere), which runs on a VM. 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. Below is a diagram of the Architecture of the JVM.
JVM is divided into three main subsystems: *** Class Loader Subsystem** *** Runtime Data Area** *** Execution Engine**
Java's dynamic class loading functionality is handled by the class loader subsystem. It loads, links. and initializes the class file when it refers to a class for the first time at runtime, not compile time.
1.1 Loading The Class loader reads the .class file, generate the corresponding binary data and save it in method area. For each .class file, JVM stores following information in method area.
- Fully qualified name of the loaded class and its immediate parent class.
- Whether .class file is related to Class or Interface or Enum
- Modifier, Variables and Method information etc.
In general there are three class loaders : After loading .class file, JVM creates an object of type Class to represent this file in the heap memory. Please note that this object is of type Class predefined in java.lang package. This Class object can be used by the programmer for getting class level information like name of class, parent name, methods and variable information etc. To get this object reference we can use getClass() method of Object class.
Boot Strap ClassLoader – Responsible for loading classes from the bootstrap classpath, nothing but rt.jar. Highest priority will be given to this loader.
Extension ClassLoader – Responsible for loading classes which are inside ext folder (jre\lib).
System/Application ClassLoader –Responsible for loading Application Level Classpath, path mentioned Environment Variable etc. he above Class Loaders will follow **Delegation Hierarchy Algorithm **while loading the class files.
1.2 Linking Performs verification, preparation, and (optionally) resolution.
- Verification : It ensures the correctness of .class file i.e. it check whether this file is properly formatted and generated by valid compiler or not. If verification fails, we get run-time exception java.lang.VerifyError.
- Preparation : JVM allocates memory for class variables and initializing the memory to default values.
- Resolution : It is the process of replacing symbolic references from the type with direct references. It is done by searching into method area to locate the referenced entity.
**1.3 Initialization ** In this phase, all static variables are assigned with their values defined in the code and static block(if any). This is executed executed from top to bottom in a class and from parent to child in class hierarchy.
Note : JVM follow Delegation-Hierarchy principle to load classes. System class loader delegate load request to extension class loader and extension class loader delegate request to boot-strap class loader. If class found in boot-strap path, class is loaded otherwise request again transfers to extension class loader and then to system class loader. At last if system class loader fails to load class, then we get run-time exception java.lang.ClassNotFoundException.
he Runtime Data Area is divided into 5 major components:
- Method Area – All the class level data will be stored here, including static variables. There is only one method area per JVM, and it is a shared resource.
- Heap Area – All the Objects and their corresponding instance variables and arrays will be stored here. There is also one Heap Area per JVM. Since the Method and Heap areas share memory for multiple threads, the data stored is not thread safe.
- Stack Area – For every thread, a separate runtime stack will be created. For every method call, one entry will be made in the stack memory which is called as Stack Frame. All local variables will be created in the stack memory. The stack area is thread safe since it is not a shared resource. The Stack Frame is divided into three subentities:
- 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.
- PC Registers – 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.
- Native Method stacks – Native Method Stack holds native method information. For every thread, a separate native method stack will be created.
It reads the byte-code line by line, use data and information present in various memory area and execute instructions. It can be classified in three parts :- 1. Interpreter – The interpreter interprets the bytecode faster, but executes slowly. The disadvantage of the interpreter is that when one method is called multiple times, every time a new interpretation is required.
2 JIT Compiler – 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. 2.1 Intermediate Code generator – Produces intermediate code **2.2 Code Optimizer **– Responsible for optimizing the intermediate code generated above **2.3 Target Code Generator **– Responsible for Generating Machine Code or Native Code 2.4 Profiler – A special component, responsible for finding hotspots, i.e. whether the method is called multiple times or not.
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.
Native Method Libraries: It is a collection of the Native Libraries which is required for the Execution Engine.