JVM stands for Java Virtual Machine.

1. Composition of JVM#

Class Loader: Loads .class files into JVM memory
Runtime Data Area: Mainly consists of Program Counter, Virtual Machine Stack, Native Method Stack, Method Area, and Heap
Execution Engine: Interprets JVM instructions, translates them into machine code, and submits them to the operating system after interpretation is complete
Native Library Interface: Native libraries that integrate different programming languages and are available for Java to call
Native Method Library: Specific implementation of Java native methods

2. Class Loader#

2.1 Classification

Bootstrap Class Loader: Loads native method classes
Extension Class Loader: Loads extension classes implemented within the JDK
System Class Loader: Loads class files from the program

2.2 Delegation Model

When loading a class file into JVM memory, the child class loader dispatches the loading request to the parent class loader, and the parent class loader performs the loading first. If the parent class loader cannot load the class file, the child class loader will load it.
System Class Loader $\rightarrow$ Extension Class Loader $\rightarrow$ Bootstrap Class Loader

3. Execution Engine#

3.1 Translation#

Just-In-Time Compiler: Saves machine code for hot code in the program and uses the saved machine code to replace the same code when encountered later.
Bytecode Interpreter: Interprets bytecode into machine code

4. Runtime Data Area#

4.1 Heap#

4.1.1 Components

Young Generation: Includes Eden and Survivor (To, From) regions
Old Generation

4.1.2 Garbage Collection Mechanism

How to Determine Garbage

Reference Counting: Allocates a reference value for each object to indicate the number of times the object is referenced, which can cause circular reference problems.
Reachability Analysis: Starts from GC roots and traverses downward. Objects that are not traversed are considered garbage;
GC roots include local variables referenced by stack frames in the virtual machine stack, local variables referenced by stack frames in the native method stack, static variables of classes in the method area, variables in the constant pool in the method area, and synchronized locking objects.

How to Collect Garbage

Mark and Sweep Algorithm, Mark and Copy Algorithm, Mark and Compact Algorithm, Generational Collection Algorithm

Classification

Young Generation Garbage Collectors: Serial, Parallel New, Parallel Scavenge
Old Generation Garbage Collectors: Serial Old, Parallel Old, CMS
Mixed: G1

When to Trigger Garbage Collection

Young GC
Triggered when the Eden region in the young generation is full. Note that some surviving objects will be promoted to the old generation during young GC, so the occupancy of the old generation usually increases after young GC.
Major GC
When the old generation reaches a certain threshold, it is performed (generally only CMS performs major GC?)
Full GC
1. When a large object is created and the Eden region cannot accommodate it, it will be directly stored in the old generation. If the old generation space is also insufficient, a Full GC will be triggered.
2. When the metaspace is full, a Full GC will be triggered.
3. When reclaiming memory during young generation garbage collection, when the surviving objects from the Eden region and Survivor From region are copied to the Survivor To region, if the size of the object is larger than the available memory in the Survivor To space, the excess objects will be moved to the old generation (this process is called allocation guarantee); At this time, if the available memory in the old generation is smaller than the size of the object, it will be judged whether to allow allocation guarantee failure; If allowed, then it will be judged whether the maximum available continuous space in the old generation is larger than the size of the objects promoted to the old generation in the past, if it is larger, a young GC will be attempted; otherwise, a Full GC will be triggered.
4. Calling System.gc()

CMS

Tri-color Marking Algorithm

Main Process

Initial Marking: STW, marks all GC roots and objects directly referenced by the young generation as gray.
Concurrent Marking: No STW, traverses the objects marked as gray and marks the traversed objects as gray and the entry objects as black, repeating the above steps.
Concurrent Preprocessing: No STW, processes and rescans dirty cards generated during concurrent marking.
Remark: STW, mainly solves the problem of misjudgment. CMS sets a write barrier to mark objects that have modified internal references as gray, and re-marks these gray objects to prevent misjudgment.
Concurrent Sweep: No STW, clears all white objects.

G1

Partitioning
G1 adopts the idea of partitioning (Region), dividing the entire heap space into several equally sized memory regions, and each allocation of object space will use memory segment by segment. Therefore, G1 does not require objects to be physically contiguous in heap usage, as long as they are logically contiguous; each partition is not necessarily dedicated to serving a certain generation, and can switch between the young and old generations as needed. The partition size can be specified at startup with the parameter -XX=n (1MB~32MB, must be a power of 2), and the entire heap is divided into 2048 partitions by default.
In G1, there is also a special region called the Humongous region. If an object occupies more than 50% of the partition capacity, the G1 collector considers it a humongous object. These humongous objects are by default allocated directly in the old generation, but if it is a short-lived humongous object, it will have a negative impact on the garbage collector. To solve this problem, G1 divides a Humongous region specifically for storing humongous objects. If an H region cannot accommodate a humongous object, G1 will search for consecutive H regions to store it. Sometimes, in order to find consecutive H regions, it is necessary to start a Full GC.
Object Allocation Strategy

TLAB (Thread Local Allocation Buffer): TLAB is a thread-local allocation buffer, which aims to allocate objects as quickly as possible. If objects are allocated in a shared space, synchronization mechanisms are needed to manage the free space pointers in these spaces. In the Eden space, each thread has a fixed partition for allocating objects, namely a TLAB. When allocating objects, there is no need for synchronization between threads.
Allocation in Eden Space: For objects that cannot be allocated in the TLAB space, the JVM will try to allocate them in the Eden space. If the Eden space cannot accommodate the object, it can only be allocated in the old generation.
Allocation in Humongous Region

Young GC Process
1. Initial Marking: STW, marks all GC roots directly associated with objects (i.e., the GC roots themselves)
2. Processing & Updating RSet: Processes the information of the RSet and scans it to add references from old generation objects to young generation objects to the GC Roots
3. Cleaning Phase: STW, packs all young regions into CSet. If the predicted recycling time is less than the given tolerance time, G1 will increase the number of regions in the Eden area without cleaning; otherwise, if the predicted recycling time is greater than the given tolerance time, G1 will perform mark-copy operations and copy all surviving objects to empty survivors.
Mixed GC Process

Initial Marking: This process is performed together with the pause process of young GC
Scanning of Root Regions
Concurrent Marking Phase: If there is a reference modification (excluding memory allocation for objects), the write barrier captures the original values of these references and records them in the log buffer. The subsequent marks are based on the original values, not the new values. For newly created objects, G1 uses a different method. G1 uses two TAMS variables to determine newly created objects. One is called the previous TAMS, and the other is called the next TAMS. Objects between the two are newly allocated objects.
Remark: STW, processes SATB write barrier objects left by each thread.
Cleaning Phase