Internal Structure | Architecture of JVM Java Virtual Machine

The Java Virtual Machine (JVM) is a virtual or abstract machine developed to execute the java programs. A Java Virtual Machine is an implementation of the Java Virtual Machine Specification which executes the Java program (byte code). This Java Virtual Machine Specification is implemented by different companies to develop the JVM.

Note: Java Virtual Machine (JVM) can be used to execute the java programs but not for compiling the java programs.

What is Java Virtual Machine Specification?

The Java Virtual Machine Specification is a document that formally describes or provides some rules for implementation of the Java Virtual Machine. For JVM there is a single Java Virtual Machine Specification which ensures that all implementations are interoperable or relevant.

JVM – Java Virtual Machine Architecture

Let’s understand the internal architecture of Java JVM; which every java programmer must know.

1. Class Loader Subsystem:

The class loader subsystem is an important part of the Java Virtual Machine which loads the java class files for execution.

The class loader subsystem dynamically performs the activities like loading, linking and initializing classes and interfaces:

I. Loading:-

Loading is the process of finding the binary representation of a class or interface type with a particular name and creating a class or interface from that binary representation.

II. Linking:-

Linking is the process of taking a class or interface and combining it into the run-time state of the Java Virtual Machine so that it can be executed.

III. Initializing:-

Initialization of a class or interface consists of executing the class or interface initialization method < clinit >

Types of Class Loader Subsystem

The Java virtual machine contains two kinds of class loaders: a bootstrap class loader and user-defined class loaders.

I. Bootstrap Class Loader Subsystem:-

Every Java virtual machine implementation has a bootstrap class loader subsystem, which knows how to load trusted classes, including the classes of the Java API. The Java virtual machine specification doesn't define how the bootstrap loader should locate classes.

II. User Defined Class Loader Subsystem:-

In a JVM, each and every class is loaded by some instance of a java.lang.ClassLoader. The ClassLoader class is located in the java.lang package and developers are free to subclass it to add their own functionality to class loading.

2. JVM Memory or Runtime Data Area:

The Runtime Data Area is divided into 5 major components:

I. 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.

II. 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.

III. 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 sub entities:

• 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.

IV. 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.

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

3 Execution Engine:

The byte code which is assigned to the Runtime Data Area will be executed by the Execution Engine. The Execution Engine reads the byte code and executes it piece by piece.

• Interpreter – The interpreter interprets the byte code 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.
• JIT Compiler – The JIT Compiler neutralizes the disadvantage of the interpreter. The Execution Engine takes help of the interpreter in converting byte code, but when it finds repeated code it uses the JIT compiler, which compiles the entire byte code and changes it to native code. This native code will be used directly for repeated method calls, which improve the performance of the system.
• Garbage Collector: Collects and removes unreferenced objects. Garbage Collection can be triggered by calling "System.gc()" or “Runtime.getRuntime().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.

Different types of Java Virtual Machine (JVM) Implementation:

1. HotSpot- the primary reference Java VM implementation provided by Oracle Corporation which comes as part of JDK and JRE.

2. OpenJDK (Open Java Development Kit) is a free and open source implementation of the Java Platform, Standard Edition (Java SE).

There are many more JVMs available, check the list of JVMs.