Many people make the mistake of thinking that the Java memory region and the memory model are the same thing, but they are not.

Java memory regions are regions where data is stored by the JVM runtime, which simply means that different data is stored in different places. Also known as the runtime data area.

The Java Memory Model (JMM) defines the access rules for variables in a program, the low-level details of storing variables into and out of memory in the virtual machine.

1. Java memory area

Before 1.8:

After JDK1.8:

The difference is that 1.8 has a metadata section instead of a method section.

JDK 1.7 is not completely removing method, but not like before 1.6 quote “Java. Lang. OutOfMemoryError: PermGen space”, but the Java lang. OutOfMemoryError: Java heap space

Part 1.7 (constant pools, static variables with method areas moved to the heap)

So why was PermGen removed from HotSpot JVM in Java 8? I’ve come up with two main reasons (see: JEP 122: Remove the Permanent Generation) :

  1. Because PermGen memory often overflows, causing annoyingjava.lang.OutOfMemoryError: PermGenTherefore, the JVM developers want this area of memory to be managed more flexibly and not to have OOM as often
  2. Removing PermGen can facilitate fusion between HotSpot JVM and JRockit VM, as JRockit has no permanent generation.

For various reasons above, PermGen was eventually removed, the method area moved to Metaspace, and string constants moved to the Java Heap.

Quote from www.sczyh30.com/posts/Java/…

Let’s take a look at each of these memory regions governed by the JVM.

2. Program counter

The Program Counter Register (Program Counter Register) is a small memory space. Since the JVM can execute threads concurrently, there will be a switch between threads. In this case, the Program Counter will record where the Program is currently executing, so that it can resume execution after other threads have finished.

The JVM assigns a program counter to each thread, the same lifetime as the thread.

If the thread is executing a Java method, this counter records the address of the virtual machine bytecode instruction being executed.

If the Native method is being executed, the counter value is null (undefined)

Program counters are the only area where the Java Virtual Machine specification does not specify any OutOfMemoryError cases.

3. Java Virtual machine stack

The virtual stack describes the memory model of Java method execution:

Each method is executed with the creation of a Stack Frame (the basic data structure of the method runtime) to store information such as local tables of variables, operand stacks, dynamic links, method exits, and so on. The process of each method from invocation to completion corresponds to the process of a stack frame being pushed into and out of the virtual machine stack.

The virtual stack is unique to each thread, existing as the thread is created and dying when the thread ends.

An OutOfMemoryError occurs when the virtual stack is out of memory, and a StackOverFlowError occurs when a larger virtual stack is required during thread running.

The virtual machine stack consists of many stack frames, one of which is created for each method execution. The stack frame in turn stores information about the method’s local variable table, operand stack, dynamic linkage, and method return address.

In an active thread, only the stack frame at the top of the stack is valid, called the current stack frame, and the method associated with this stack frame is called the current method.

1) Local variation scale

A local variable table is an area where method parameters and local variables are stored.

Global variables are placed in the heap, and there are two assignment phases, one in preparation for class loading, which gives the system its initial value; Another time, during class load initialization, the code is given the initial values defined by the class.

Local variables cannot be used without an initial value.

2) Operand stack

A first in, last out stack.

When a method is first executed, the operand stack of the method is empty. During the execution of the method, various bytecode instructions are written to and extracted from the operand stack.

3) Dynamic connection

Each stack frame contains a reference to the method that the stack frame belongs to in the runtime constant pool. This reference is held to support Dynamic Linking during method invocation.

Constant pools facilitate instruction identification

    public void methodA(a){}public void methodB(a){
        methodA();//methodB() calls methodA()
    }
Copy the code

Method invocation is not the same as method execution. The only task in the method invocation phase is to determine the version of the called method (i.e. which method to call). This is also Java’s powerful extensibility capability, and only at runtime can determine the direct reference to the target method.

The target method in all method calls is a constant pool of symbolic references in the Class file, some of which are converted to direct references during the parsing phase of the Class load.

4) Method return address (method exit)

Returns are classified into normal returns and abnormal exits.

In either case, the method is returned to where it was currently called, and the program can continue executing.

In general, when a method exits normally, the value of the caller’s PC counter can be used as the return address, and this counter value is stored in the stack frame.

Method exit is equivalent to popping up the current stack frame.

4. Local method stack

The Java virtual machine stack calls Java methods; The local method stack is to call the native method, which can be considered as a direct call to the local C/C++ library through the Java Native Interface (JNI), which is not controlled by the JVM.

StackOverflowError and OutOfMemoryError exceptions are also thrown by the local method stack

5, the Java heap

The Java heap is an area of memory that is shared by all threads and is created when the virtual machine is started. The sole purpose of this memory area is to hold object instances, and almost all object instances are allocated memory here.

The heap is the primary area managed by the garbage collector, also known as the “GC heap,” and is arguably the largest chunk of memory managed by the Java Virtual machine.

Today’s virtual machines (including HotSpot VM) use generational recycling algorithms. In the idea of generational recycling, the heap is divided into: New generation + old age + permanent generation (1.8 is gone); The new generation is divided into Eden + From Survivor + To Survivor area.

6. Method area

The Method Area, like the Java heap, is an Area of memory shared by all threads.

The method area is used to store the class information that has been loaded by the VIRTUAL machine (that is, the information that needs to be loaded when the class is loaded, including the version, field, method, interface, etc.), final constants, static variables, and code compiled by the compiler on the spot.

The method area is logically part of the heap, but is often referred to as “non-heap” to distinguish it from the heap.

An important part of the method area is the Runtime Constant Pool. It is possible to put new constants into the pool during runtime, such as the common intern() method of String.

String a = "I am HaC";
Integer b = 100;
Copy the code

At compile time, all string literals are put into a constant pool and reused (such as “I am HaC” above) to save space.

On the relationship between method area and meta-space:

The method area is a JVM specification concept, while the permanent generation is a Hotspot VIRTUAL machine specific concept. Simple to understand: the method area and the permanent generation of heap memory are actually the same thing, but the method area contains the permanent generation.

Only HotSpot has a “PermGen Space”, for other types of virtual machines such as JRockit (Oracle), J9 (IBM), there is no “PermGen space”.

7. Meta-space

In 1.8, the method area is changed to a metaspace. The meta-information for a class is stored in a meta-space. The meta space does not use heap memory, but is a local memory region not connected to the heap. So, in theory, the meta-space is as large as the memory the system can use, so there is no memory overflow problem in the presence of permanent generations.

You can specify the size of the MetaspaceSize by -xx :MetaspaceSize or -xx :MaxMetaspaceSize.

8. Summary:

Reference:

-rain.baimuxym.cn/article/14

  • In-depth Understanding of the Java Virtual Machine
  • Code Efficient