The JVM (Java Virtual Machine) is one of the most commonly asked questions in a job interview. This article focuses on the composition of the JVM.
The components of the JVM are divided into the overall component and the run-time data area component. The latter is what most developers focus on and interviewers ask about, but this article will cover the above two components in detail.
First, the overall composition of JVM
The overall composition of the JVM can be divided into the following four parts:
-
ClassLoader
-
Runtime Data Area
-
Execution Engine
-
Native Library Interface
Purpose of each component:
Before executing a program, Java code is converted into a bytecode (bytecode) file. The JVM first loads the bytecode into the Runtime Data Area of memory by a ClassLoader. The bytecode file is an instruction set specification of the JVM and cannot be delivered directly to the underlying operating system for Execution. Therefore, a specific command parser Execution Engine is required to translate the bytecode into the underlying system instructions for Execution by the CPU. In this process, it is necessary to call the Native Interface of other languages to realize the function of the whole program, which is the responsibility and function of these four main components.
The JVM component we usually refer to is the Runtime Data Area, because the Area that programmers debug and analyze is the Runtime Data Area, or more specifically the Heap module within the Runtime Data Area. Now let’s look at the modules that make up the Runtime Data Area.
2. Composition of runtime data area
The runtime data areas of the JVM may vary slightly from vm to VM, but all comply with the Java Virtual Machine specification. According to the Java 8 VIRTUAL Machine Specification, the memory managed by the Java VIRTUAL machine will include the following runtime data areas:
-
Program Counter Register
-
Java Virtual Machine Stacks
-
Native Method Stack
-
Java Heap
-
Methed Area
Next, we introduce the purpose of each area separately.
(1), Java,Program counter
The Program Counter Register is a small memory space that can be thought of as a line number indicator of the bytecode being executed by the current thread. In the conceptual model of a virtual machine, the bytecode parser’s job is to change the value of this counter to select the next bytecode instruction to be executed. Branches, loops, jumps, exception handling, thread recovery and other basic functions depend on this counter.
Feature: Memory private
Since JVM multithreading is implemented by switching threads and allocating processor execution time, one processor (or kernel) is only executing instructions in one thread at any one time. Therefore, each thread has its own program counter in order to return to the correct execution position after switching.
Exception rule: None
If the thread is executing a Java method, the program counter records the address of the vm bytecode instruction being executed. If the thread is executing a Native method, the counter is null. This memory region is therefore the only one where OutOfMemoryError is not specified in the Java Virtual Machine specification.
② Java virtual machine stack
Java Virtual Machine Stacks describe the memory model of Java method execution. Each method execution creates a Stack Frame for storing information about local variables, operand Stacks, dynamic links, method exits, etc. Each method, from invocation to completion, corresponds to the process of a line frame in the virtual machine stack and out of the stack.
Features: Memory is private and has the same life cycle as threads.
Exceptions include StackOverflowError and OutOfMemoryError
A StackOverflowError is raised if the thread requests a stack depth larger than the virtual machine allows.
2. If the VIRTUAL machine is dynamically scalable, OutOfMemoryError will be raised if sufficient memory cannot be allocated during the extension.
Local method stack
The Native Method Stack serves the same function as the virtual machine Stack, except that the virtual machine Stack serves Java methods, while the Native Method Stack serves Native methods for virtual machines.
There are no special requirements in the Java Virtual Machine specification for the local method stack and the virtual machine is free to implement it, so the Sun HotSpot VIRTUAL machine combines the local method stack and the virtual machine stack directly.
Features and exceptions: The same as the vm stack.
(4), the Java heap
The Java Heap is the largest chunk of memory in the Java VIRTUAL machine, which is shared by all threads. It is created when the virtual machine is started. The sole purpose of the Java Heap is to hold object instances. Stack allocation, scalar substitution optimization techniques will lead to subtle changes where all objects allocated on the heap become less “absolute”.
Feature: Memory sharing
Exception rule: OutOfMemoryError
OutOfMemoryError is raised if there is no memory in the heap to complete the instance allocation and the heap cannot be extended.
The Java Virtual Machine specification states that the Java heap can be in a physically discontinuous memory space, as long as it is logically continuous, like our disk space. The implementation can be either fixed size or extensible, but most current virtual machines are extensible, controlled by -xmx and -xMS.
⑤, method area
The Methed Area is used to store data such as class information, constants, static variables, and just-in-time compiled code that have been loaded by the virtual machine.
Myth: Method area does not equal immortal generation
Many people refer to the method area as “Permanent Generation”, which is not necessarily equivalent, but the HotSpot VIRTUAL machine garbage collector team has extended GC Generation collection to the method area, or Permanent Generation to implement the method area. This eliminates the need to write memory-management code specifically for method areas, but in Jdk8 it also removes the “persistent generation” and uses Native Memory to implement method areas.
Feature: Memory sharing
Exception rule: OutOfMemoryError
An OutOfMemoryError is thrown when a method cannot meet memory allocation requirements.
Third, expand knowledge
This section will expand on some of the knowledge related to memory allocation.
Run-time constant pool
The Constant Pool Table is used to store various literal and symbolic references generated at compile time. The Constant Pool Table is used to store all literal and symbolic references generated at compile time after the Class is loaded into the method area. Like the intern() method of the String class.
Direct memory
Direct Memory is not part of the data portion of a running VIRTUAL machine, but it is frequently used and may cause OutofMemoryErrors. In JDK 1.4, the NIO class introduced a Channel – and buffer-based IO that referenced the block of memory via a DirectByteBuffer object stored in the Java heap. It avoids the time spent exchanging data back and forth between the Java heap and Native heap.
Note: Direct memory allocation is not limited by the Java heap size, but is limited by the total local memory size. When setting VM parameters, do not ignore direct memory. If the actual memory is set to -xmx, the total memory area is greater than the physical memory limit, resulting in OutOfMemoryError during dynamic expansion.
Four,
In this article, we discussed the main components of the JVM and the most important Runtime Data Area of the component. The program counters, virtual stack, and local methods are private memory, which is created and killed by a thread. The Java heap as the largest memory region will be the focus of the developers of the memory region, as well as the method area and the runtime constant area and eternal generation of the relationship, finally talked about the direct memory implementation process has been used to need the main point, I hope to help you better understand the JVM.
5. Reference materials
In-depth Understanding of the Java Virtual Machine
“The End”
Follow the QR code below and subscribe for more exciting content.
