Java Virtual Machine (JVM) & its Architecture

Hello readers! In this article we will learn about JVM architecture and this article will help you to answer all the JVM based interview questions correctly.

What is JVM?

JVM is a engine that provides runtime environment to drive the Java Code or applications. It converts Java bytecode into machines language. JVM is a part of JRE(Java Run Environment). It stands for Java Virtual Machine

• In other programming languages, the compiler produces machine code for a particular system. However, Java compiler produces code for a Virtual Machine known as Java Virtual Machine.
• First, Java code is complied into bytecode. This bytecode gets interpreted on different machines
• Between host system and Java source, Bytecode is an intermediary language.
• JVM is responsible for allocating memory space.

JVM Architecture

Let's understand the Architecture of JVM. It contains classloader, memory area, execution engine etc.

1.1 ClassLoader Subsystem

The classloader subsystem is an essential core of the Java Virtual machine and is used for loading/reading the .class files and saving the bytecode in the JVM method area. This subsystem handles the dynamic class loading functionality and performs three major functions i.e.:

• Loading: This component handles the loading of the .class files from the hardware system into the JVM memory and stores the binary data (such as fully qualified class-name, immediate parent class-name, information about methods, variables, constructors etc.) in the method areas. For every loaded .class file, JVM immediately creates an object on the heap memory of type java.lang.class. Do remember, even though the developers call a class multiple time, only one class object will be created. There are three main types of classloaders:
  • Bootstrap or Primordial ClassLoader: This classloader is responsible for loading the internal core java classes present in the rt.jar and other classes present in the java.lang.* package. It is by-default available with every JVM and is written in native C/C++ languages. This classloader has no parents and if developers call the String.class.getClassLoader(), it will return null and any code based on that will throw the NullPointerException in Java
  • Extension ClassLoader: This classloader is the child class of Primordial classloader and is responsible for loading the classes from the extension classpath (i.e. jdk\jre\lib\ext). It is written in Java language and the corresponding .class file is sun.misc.Launcher$ExtClassLoder.class
  • Application or System ClassLoader: This classloader is the child class of Extension classloader and is responsible for loading the classes from the system classpath. It internally uses the ‘CLASSPATH‘ environment variable and is written in Java language. System classloader in JVM is implemented by sun.misc.Launcher$AppClassLoader.class
• Linking: This component performs the linking of a class or an interface. As this component involves the allocation of new data structures, it may throw the OutOfMemoryError and performs the three important activities:
  • Verification: It is a process of checking the binary representation of a class and validating whether the generated .class file is valid or not. This process is performed by the Bytecode verifier and if the generated .class file is notvalid, a VerifyError is thrown
  • Preparation: It is a process of assigning the memory for the class level or interface level static variables and assigns the default values
  • Resolution: It is a process of changing the symbolic references with the original memory references from the method area
• Initialization: This component performs the final phase of the class loading where all the static variables are assigned the original values and the static blocks are executed from the parent to the child class. This process requires careful synchronization as JVM is multithreaded and some threads may try to initialize the same class or interface at the same time.

Fig. 3: An overview of ClassLoader Subsystem

1.2 Runtime Data Areas

As shown in Fig. 5, this subsystem is divided into five major components i.e.

Fig. 5: JVM Runtime Data Areas

• Method Area: This component holds the class level data of each .class file such as metadata, constant runtime pool, static variables, the code for the methods etc. There is only one method area per JVM and is shared among all the classes. The memory allocated to this area is by-default allocated by the JVM or can be increased as per the computation needs. The following exceptional condition is associated with this area i.e.
  • If the method area is not available to satisfy a memory allocation request, the JVM throws an OutOfMemory error
• Heap Area: This component is a part of JVM memory where all the objects and its corresponding instance variables and arrays are stored. This memory area is created on the JVM start-up and there is only one heap area shared across multiple threads as the data stored in this area is not thread-safe. If the objects stored in the heap memory have no reference, memory for that object is reclaimed by the garbage collector (i.e. the automatic storage management system); objects in this area are never explicitly deallocated. The following exceptional condition is associated with this area i.e.
  • If the computation requires more heap area than the available, JVM throws an OutOfMemory error
• Stack Area: This component is again a part of JVM memory where all the temporary variables are stored. This area has stack frames and allocates one frame for each thread. Once the thread execution is completed, this frame also gets destroyed. The stack area is thread-safe as it is not a shared resource and is divided into three sub-entities such as:
  • Local variable array: These local variables are used by the virtual machine to pass the parameters upon the method invocation
  • Operand Stack: This place is the actual place to perform operations during a method execution. The virtual machine takes the operand from the stack, operates on them, and pushes the result back onto the operand stack. This stack also prepares the arguments to be passed to a method and even to receive the method results
  • Frame data
  The following exceptional condition is associated with this area i.e.
  • If the thread processing requires the virtual machine stack than its permissible limit, the JVM throws a StackOverflowerror
  • If the virtual machine stack is insufficiently expanded, the JVM throws a OutOfMemory error
• PC (Program Counter) Registers: This component holds the address of the JVM instruction which is currently executing. Each thread in Java has its own PC register to hold the address of the currently executing instruction
• Native Method Stacks: This component is written in a different language and holds the native method information. Every thread in Java has a separate native method stack. The following exceptional condition is associated with this area i.e.
• If the thread processing requires the native stack than its permissible limit, the JVM throws a StackOverflow error
• If the native method stack is insufficiently expanded, the JVM throws a OutOfMemory error

1.3 Execution Engine

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

• Interpreter – Reads the bytecode, interprets it and executes it one by one. The interpreter interprets the bytecode faster but executes slowly. The disadvantage of the interpreter is that when one method called multiple times, every time interpretation is required.

• JIT Compiler – JIT Compiler neutralizes the disadvantage of the Interpreter ( a single method called multiple times, each time interpretation is required ), The Execution Engine will be using the help of Interpreter in converting but when it found repeated code it uses 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 – Code Optimizer is responsible for optimizing the intermediate code generated above
• Target Code Generator – Target Code Generator is responsible for Generating Machine Code/ Native Code

• Profiler – Profiler is a special component, it is responsible for finding the hotspots (i.e) Used to identify whether the method is called multiple time or not.

• Garbage Collector : Garbage Collector is a part of Execution Engine, it collects/removes the unreferenced objects. Garbage Collection can be triggered by calling “System.gc()”, but the execution is not guaranteed. Garbage collector of JVM collects only those objects that are created by new keyword. So if you have created any object without new, you can use finalize method to perform cleanup.

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

2. Software Code Compilation & Execution process

In order to write and execute a software program, you need the following

1) Editor – To type your program into, a notepad could be used for this

2) Compiler – To convert your high language program into native machine code

3) Linker – To combine different program files reference in your main program together.

4) Loader – To load the files from your secondary storage device like Hard Disk, Flash Drive, CD into RAM for execution. The loading is automatically done when you execute your code.

5) Execution – Actual execution of the code which is handled by your OS & processor.

That’s all for this post. Happy Learning!