Java Virtual Machine

Maduranjana janakantha
5 min readJul 16, 2022
Photo by Emile Perron on Unsplash

The core of the Java platform is the Java Virtual Machine. It is the component of the technology that is in responsibility of the system’s independence from specific hardware and operating systems, the small size of its compiled code, and its potential to safeguard users from viruses and other malicious.

An conceptual computer system is the Java Virtual Machine. It has a set of instructions and can run-time alter different memory regions. A virtual machine is widely used to implement programming languages.

JDK vs JRE vs JVM

JVM is a part of JRE(Java Runtime Environment). The Java Virtual Machine only recognizes a particular binary format, the class file format, and has no understanding of the Java programming language. A class file includes a symbol table, Java Virtual Machine instructions(or bytecodes), and other supporting information.

Java Architecture

Java applications are called WORA (Write Once Run Anywhere).This suggests that a programmer could write Java code on one system and expect it to execute correctly on any other machine that supports Java. Java applications are run using the JVM as a run-time engine.

Inside Java Virtual Machine

Any programming language requires a specific environment with all the essential components, application programming interfaces, and compilers to create, compile, test, and run its applications. Java source codes are converted during compilation into a process known as bytecode. use the JDK’s built-in Java Compiler (javac). This bytecode has opcode-operand lines and is formatted in hexadecimal and These instructions can be interpreted by JVM into native machine language that the OS and underlying hardware platform can understand.

JVM Architecture

Class Loader Subsystem

The RAM is dedicated to the JVM. The Class Loader subsystem is used to get the class files onto the RAM when the JVM is running. its is called Java’s “dynamic class loading” function.

Class Loader Subsystem

Loading

The basic task of Class Loader is to load compiled classes(.class) into memory. Following class loading attempts are made in accordance with the class references in the active classes as mentioned in the following cases:

bytecode make a static reference to a class — Employee.sign

bytecode create a class object — Employee employee = new Employee()

Linking

In order to link a loaded class or interface, its direct super-classes and super-interfaces, and its element type as needed, the following attributes must be followed.

Initialization

Each loaded class or interface’s initialization code will be run. A class or interface’s initialization should be done carefully and with the appropriate synchronization since the JVM is multi-threaded. This is the final phase of class loading where all the static variables are assigned with their original values defined in the code and the static block will be executed

Runtime Data Area

The memory areas assigned when the JVM application is running on the operating system are known as runtime data areas. The Class Loader subsystem creates matching binary data and saves the following details in the Method area for each class independently in addition to reading .class files.

Runtime Data Area

Method Area

All JVM threads have access to the same Method area, hence dynamic linking and data access to the Method area must be thread-safe. This is a shared resource but “only 1 method area per JVM”

Heap Area

The Heap area serves as a storage place for all object information as well as instance variables and arrays that go with each object. The data stored in the Method and Heap sections is not thread safe since they share memory with multiple threads. This is area also shared resource but “only 1 method area per JVM”

Stack Area

A separate runtime stack is generated when the thread begins to store method calls, This is not a shared resource. Regarding each JVM thread. One record will be generated and added (pushed) to the top of the runtime stack for each such method call; this entry is known as a Stack Frame.

PC Registers

To hold the address of the currently-executing instruction, a separate Program Counter Register is generated when the thread initially begins Regarding each JVM thread. The address of the next instruction is modified in the PC register after execution is finished.

Native Method Stack

A Java thread and a native operating system thread have a direct mapping. A separate native stack is also constructed to store information about native methods after establishing all the state for a Java thread. The run() method in the Java thread is called once the native thread has been established and initialized.

Execution Engine

Execution Engine executes the instructions in the bytecode line-by-line by reading the data assigned to above runtime data areas. This is where the bytecode is actually executed.

Execution Engine

Interpreter

The instructions are performed out one at a time by the interpreter, that interprets the bytecode. It can quickly interpret one line of bytecode, but executing the output takes longer.

Just-In-Time (JIT) Compiler

it compiles the entire bytecode to native code (machine code). It then directly provides the native code for repeated method calls, and native code execution is significantly quicker than interpreting instructions one at a time. The native code is stored in the cache, thus the compiled code can be executed quicker.

Garbage Collector

the garbage collector removes and reclaims the unused memory. As long as an object is being referenced, the JVM considers it alive. The garbage collector eliminates an object after it is no longer referenced and hence not available by the application code, clearing up the memory that it consumed.

--

--