It is hard to forget the facts.

Java Virtual Machine (Java Virtual Machine) hereinafter referred to as JVM, last article we have a general understanding of the JVM, into this article we will be specific and detailed introduction to all aspects of the JVM, and this article is mainly about the composition of the JVM, to understand it, to uncover the mystery of the JVM.

The main components of the JVM

  1. ClassLoader
  2. Runtime Data Area
  3. Execution Engine
  4. Native Library Interface

Let’s look at the uses of the four main components.

Second, the purpose of JVM components

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.

Three, run time 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:

  1. Program Counter Register
  2. Java Virtual Machine Stacks
  3. Native Method Stack
  4. Java Heap
  5. Methed Area

Next, we introduce the purpose of each area separately.

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

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

3.3 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. For details, see 3.2.

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

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

Fourth, expand knowledge

This section will expand on some of the knowledge related to memory allocation.

4.1 Runtime 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.

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

Five, the summary

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.

Vi. Reference materials

The following describes the memory composition and heap memory of the Java VIRTUAL machine: t.cn/EqVvZui

Md: t.cn/Eq6Vmuo

The JVM memory model: t.cn/EqVvxOS

JVM (2):JVM memory structure: t.cn/RB8i3RN

Reference Book: Understanding the Java Virtual Machine in Depth

The last

Pay attention to the author’s public account, learn more exciting content:

If you find this article helpful, please forward it to moments or share it directly with your friends.