About JVM Architecture

JVM - Java Virtual Machine

• JVM is a software (set of programs) that converts Java bytecode into operating system understandable (machine) code.
• The main work of JVM is to load the .class file into JVM memory and execute it.
• JVM is called a virtual machine because it runs Java programs like a real computer in software .
• Means , JVM is not a physical machine, but it behaves lust like a computer for running Java programs .

• A machine is anything that performs work or executes tasks using energy, taking input, processing it, and producing output.

• It also manages memory and provides garbage collection facility.

• JVM memory is the memory area provided by the OS from RAM, which is organized by JVM to store everything of a Java program, such as objects, fields, variables, class information, and more.

• JVM uses an interpreter and JIT compiler to run bytecode faster.

JVM Architecture

• JVM Architecture means how JVM is designed internally, or how it works internally – how it loads .class files, executes them, and manages memory .

• Entire JVM is divided into 3 - parts

  • 1 . Class Loader Sub system
  • 2. Runtime Data Area (Memory Area )
  • 3. Execution Engine ( Interpreter & JIT Compiler )

1 . Class Loader Sub system

• Class Loader Subsystem is a part of JVM and is considered the first layer of JVM.
• The main purpose of Class Loader Sub System is to load the .class file into JVM memory ( Method Area ) from Various location .
• During class loading, static field(s) get memory and are initialized with default values in the prepare phase, and static blocks are executed in the initialization phase.
  • Prepare Phase → Allocate memory for static fields + set default values.
  • Initialization Phase → Execute static blocks + assign developer-specified values to static fields.
• Class Loader Subsystem internally follows an algorithm called the Delegation Hierarchy Algorithm.
• Delegation Hierarchy Algorithm is a technique by which JVM tries to load a .class file into JVM memory. The class loading request first goes from the child class loader to the parent class loader. If the parent loads the required predefined class, the control is returned to the child class loader;

• Class Loader Subsystem performs three main tasks internally :

  • a. Loading
  • b. Linking
  • c. Initialization

a. Loading Phase

• Loading phase responsibility is to load the .class file into JVM memory (Method Area) and return a Class object.
• Loading Phase consists of 3 class Loader
  • Bootstrap class Loader (Primordial Class Loader)
  • Platform Class Loader ( Extension Class Loader )
  • Application Class Loader ( System Class Loader ).

Bootstrap class Loader (Primordial Class Loader)

• Bootstrap Class Loader (BCL) is the parent (super) class loader of the Platform Class Loader.
• The main responsibility of the Bootstrap Class Loader is to load core Java classes (like Object, String, System, etc.).
• These core classes are loaded from the jrt-fs.jar file .
• Path of jrt-fs.jar:
  • C:\Program Files\Java\JDK\lib\jrt-fs.jar
• The first class loaded by the Bootstrap Class Loader is java.lang.Object.
• The .class file is stored in the Method Area, and a Class object for that class is returned.
• Bootstrap class loader is the virtual machine's built-in class loader, typically represented as null, and does not have a parent.

Platform Class Loader ( Extension Class Loader )

• Platform Class Loader is a child of Bootstrap Class Loader and a parent of Application Class Loader.
• Loaded .class files are stored in the Method Area, and a Class object is returned.
• The .class file is stored in the Method Area, and a Class object for that class is returned.

Note :

• Before Java 9 , This is known as Extension Class Loader .
• This is because before Java 9, JVM loads the extension / optional (non-core) jar files from the ext (extension) folder.

• Path :

  • C → Program Files → Java → JDK → lib → ext (extension folder) → extension / optional (non-core) JAR files.

• But from Java 9 onwards, JVM loads the extension / optional (non-core) libraries through the Java Platform Module System (JPMS), instead of the ext folder.

• Path :

  • C → Program Files → Java → JDK → lib → modules → Java platform modules (optional / non-core) .

Application Class Loader ( System Class Loader )

• Application Class Loader is subclass of Platform Class Loader.
• Its main responsibility is to load all user-defined .class files into the JVM memory .
• It loads the .class file from class file path or environment Variable .
• For Application Class Loader, the .class file is loaded into the Method Area and a corresponding Class object is returned by the JVM.

Note :

• If all the class loaders are not able to load the .class file into the JVM memory then we get runtime called java.lang.ClassNotFoundException .

b. Linking Phase

• Linking phase responsibility is to check the .class file, set up memory for static variables, and connect references.
• In other words, linking phase verifies, prepares, and resolves the .class file in JVM memory (Method Area).
• Linking phase does 3 tasks:
  • Verify → Check the .class file
  • Prepare → Set up memory for static variables
  • Resolve → Connect symbolic references to actual memory addresses

Verify (Check the .class file)

• Verify checks the correctness of the .class file. If the .class file is invalid or contains suspicious/illegal bytecode, JVM immediately throws a runtime error called java.lang.VerifyError.
• Bytecode Verifier (component of JVM) is responsible for verifying the .class file.
• Verify, with the help of Bytecode Verifier, checks the .class file for correctness and safety.
• java.lang.VerifyError is a subclass of java.lang.LinkageError.

Prepare → Set up memory for static variables

• Prepare phase responsibility is to allocate memory for static fields (primitive or reference) and assign default values.
• For reference static fields:
  • On a 32-bit system → 4 bytes of memory are allocated
  • On a 64-bit system → 8 bytes of memory are allocated
  • for reference types / Objects, the default value is always null

Resolve → Connect symbolic references to actual memory addresses

• Resolve phase responsibility is to connect symbolic references in the .class file to actual memory addresses.
• Symbolic references include classes, methods, and fields used by the class.
• JVM replaces these symbolic names with direct references in memory.

// command to get complete info about a compiled .class file
javap -verbose className.class

c. Initialization phase

• Initialization phase responsibility is to assign original values to static fields and execute static blocks.
• Static fields initialization and static blocks have the same priority, so they are executed in the order they appear in the source code (top to bottom).

Notes:

• Before JDK 1.7, JVM checked the main() method after executing static members (static variables and static blocks).
• From JDK 1.7 onwards, JVM checks the presence of a valid main() method before executing static variables and static blocks.
• So, before Java 1.7, static blocks execute even without main(), but from Java 1.7 onwards, the presence of main() controls whether static blocks execute or not.

RunTime Data Area ( Memory Areas )

• Runtime Data Area is a part of the JVM and represents the memory created during program execution.
• It is also known as Memory Areas of the JVM.

• They are called Runtime Data Areas because these memory areas are created and used only when the program is running (at runtime).

• JVM allocates, manages, and releases these areas during program execution, not at compile time.

• JVM memory is divided into five Runtime Data Areas depending on variable type, method information, and execution requirements.
  ....

    Will continue…