JVM runtime data area (leafage.top)

JVM runtime data is divided into:

  1. Program counter;
  2. Virtual machine stack;
  3. Local method stack;
  4. Heap;
  5. Methods area;

The heap and method area are shared by threads, while the program counter, virtual machine stack and local method stack are thread isolated. The structure is shown as follows:

1. Program counter:

Multithreading in the Java VIRTUAL machine is implemented by the way that threads alternate and allocate processor execution time. At any given time, one processor (or core for multi-core processors) will execute instructions in only one thread.

To thread after switching to restore to the execution of the right position, each thread requires a separate program counter, what can be thought of as the current thread execute the number of rows in the bytecode indicator (storage address of the next instruction), the instructions to be executed code, counter each other between every thread, independent storage.

You can view specific information in the debug mode of the idea:

Its characteristics are:

  • A program counter is a small piece of memory that is thread private;
  • Record the address of the bytecode instruction when the non-local method is executed. If the local method is executed, the value is undefined.
  • The only area where the Java Virtual Machine Specification does not specify any OutOfMemoryError cases;

2. Vm stack:

The virtual machine Stack describes the thread-memory model of Java method execution: each Java virtual machine thread is created with a separate virtual machine Stack, which holds Stack frames for each method call.

The stack frame:

The contents of thread execution methods are stored in the stack frame, and each method has its own stack frame, while for multi-layer nested call methods, the stack frame is set to the stack according to the call chain of the method (stack operation is first in, last out), as shown in the following example:

Again, you can see the effect with code debug:

Each Stack Frame stores:

  1. Local Variables;
  2. Operand Stack;
  3. Dynamic Linking: method reference pointing to the runtime constant pool;
  4. Return Address: Additional information about the Address at which a method exits normally or abnormally.
  5. Additional information

The sample diagram of stack frame structure is as follows:

3. Local method stack:

What are local methods?

A: Written in another language and compiled into processor-specific machine code.

Local methods are stored in a dynamic link library, a. DLL (Windows) file, in a platform-specific format (Java is platform-independent, but native methods are not, which is why the JDK comes in Linux, Windows, and MacOS versions).

Why use local methods?

A: There are several reasons for using the local method:

  1. Interact diplomatically with the Java environment: Sometimes Java applications need to interact with environments outside of Java;
  2. Interaction with the operating system: The JVM supports the Java language itself and runtime libraries, but sometimes still relies on support from some underlying system. With the native approach, we can use Java to interact with the underlying system that implements the JRE, some parts of which are written in C.
  3. Sun’s Java: Sun’s interpreter is implemented in C, which allows it to interact with the outside world just like normal C. For example, the setPriority() method of java.lang.Thread is implemented in Java, but its implementation calls the class’s native method setPrioruty(), which is implemented in C and built into the JVM.

Local method stack features:

  • Thread private, which allows a thread to have a fixed or dynamically expandable memory size (like the virtual stack) :
    • StackOverflowError is raised if the thread requests a stack depth greater than the virtual machine allows.
    • If the Java virtual machine stack can be dynamically expanded (HotSpot virtual machine stack cannot be dynamically expanded), an OutOfMemoryError will be raised if sufficient memory cannot be allocated during stack expansion.
  • Access the runtime data area inside the VIRTUAL machine through the local method interface;
  • Not all JVMS support native methods. The Java Virtual Machine Specification does not specify the language, implementation or data structure of the local method stack.
  • In the HotSpot VIRTUAL machine, the virtual machine stack and the local method stack are merged into one.

4. The stack:

For most applications, the Java heap is the largest chunk of memory managed by the Java Virtual machine and is shared by all threads. The sole purpose of this memory area is to hold object instances, and almost all object instances and data are allocated in memory here.

For efficient garbage collection, the virtual machine logically divides the heap memory into three areas, just for better collection or faster allocation of memory.

The default ratio of the memory size in the old generation to that in the young generation is 2:1. The default minimum memory size is: OPERATING system memory /64. The default maximum memory size is: operating system memory /4.

We can use the code to see if it is consistent with the description:

public class HeapMemory {

    public static void main(String[] args) {
        // Returns the JVM heap size
        long initalMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024;
        // Returns the maximum memory of the JVM heap
        long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024;

        System.out.println("-Xms : " + initalMemory + "M");
        System.out.println("-Xmx : " + maxMemory + "M");

        System.out.println("System memory size:" + initalMemory * 64 / 1024 + "G");
        System.out.println("System memory size:" + maxMemory * 4 / 1024 + "G"); }}Copy the code

The running results are as follows:

D:\env\jdk11\bin\java.exe ... N/a Xms: 250M n/a Xmx: 3996M system memory: 15 gb system memory: 15 gbCopy the code

Speaking of the heap, there is an important concept called garbage collection, and JVM garbage collection has different execution strategies or algorithms for different generations.

What are Minor, Major, Mixed, and Full GC?

A: When GC is performed, not all heap memory (new generation, old age; Most of the time, it’s the Cenozoic generation.

For the implementation of HotSpot VM, the GC in it is divided into two main categories according to the collection region:

  1. Partial collection: Garbage collection that does not collect the entire Java heap. Which are divided into:
    • Minor GC: Only garbage collection for the new generation;
    • Major GC: Just old GC;
    • Mixed GC: Collects garbage from the entire Cenozoic generation and parts of the old generation (currently only G1 GC does this);
  2. Full GC: Collects garbage from the entire Java heap and method area;

5. Method Area:

The method area stores data such as type information that has been loaded by virtual machine, constants, static variables, and code cache compiled by immediate compiler.

Many people prefer to refer to method regions as “PermanentGeneration” or lump the two together. The two are not essentially equivalent, as it was only the HotSpot VIRTUAL machine design team that chose to extend the generational design of the collector to the method area, or to implement the method area using persistent generations, which allowed the HotSpot garbage collector to manage this part of memory as well as the Java heap. Save the effort of writing memory-management code specifically for the method area.

The method area has undergone several major changes over the course of JDK development. The most important changes are in JDK6, JDK7, and JDK8.

  1. JDK6 –> JDK7: string constant pool, static variables removed from the old age, put in the heap;
  2. JDK7 –> JDK8 –> JDK8 –> JDK8:

Examples of changes are shown below:

Why would I replace permanent generations with a meta-space?

A: The reasons are as follows:

  1. Setting the size of the space for the permanent generation is difficult to determine;

In some scenarios, if too many classes are dynamically loaded, OOM in the Perm area may be generated. If a practical Web project, because there are many function points, in the process of running, to dynamically load many classes, often OOM. The biggest difference between a meta-space and a permanent generation is that the meta-space does not exist in a VM. Instead, it uses local memory. Therefore, by default, the size of a meta-space is limited only by the local memory

  1. It is difficult to tune permanent generation.