Shulou(Shulou.com)06/01 Report--

This article Xiaobian for you to introduce in detail "how to allocate the memory area in the Java virtual machine", the content is detailed, the steps are clear, and the details are handled properly. I hope this article "how to allocate the memory area in the Java virtual machine" can help you solve your doubts.

01. Program counter

The program counter (Program Counter Register) takes up a small amount of memory and can be regarded as a line number indicator of bytecode instructions executed by the current thread. The bytecode interpreter will change the value of this counter while working to select the next bytecode instruction to be executed, such as branch, loop, jump, exception handling, thread recovery and other functions need to rely on this counter.

In JVM, multithreading obtains CPU execution time through thread switching in turn. Therefore, at any specific moment, the kernel of a CPU will only execute instructions in one thread. Therefore, in order to restore to the correct execution position after thread switching, each thread needs to have an independent program counter and can not interfere with each other, otherwise the normal execution order of the program will be affected.

That is, we require the program counter to be thread private.

The Java Virtual Machine Specification states that if a thread is executing a native method, the address of the instruction that currently needs to be executed is stored in the program counter; if the thread is executing a local method, the value in the program counter is undefined.

Why is the value of the local method in the program counter undefined? Because most of the local methods are implemented through CCompact +, they are not compiled into bytecode instructions that need to be executed.

Because the space occupied by the data stored in the program counter will not change with the execution of the program, the program counter will not have memory overflow (OutOfMemory).

02. Java virtual machine stack

There are stack frames in the Java virtual machine stack, and each stack frame corresponds to a called method. When a thread executes a method, it creates a corresponding stack frame and presses the stack frame into the stack. When the method is executed, the stack frame is removed from the stack. The stack follows the last-in-first-out principle, so the stack frame corresponding to the method currently executed by the thread must be at the top of the Java virtual machine stack.

1. Local variable scale

As the name implies, it is used to store local variables in a method, including the parameters of the method. For variables of basic data types, the values of variables are stored directly; for variables of reference types, references to objects are stored. The size of the local variable table is determined during compilation, and its size will not change during program execution.

two。 Operand stack

The expression is evaluated in the Operand stack. When a method is first executed, the Operand stack of the method is empty. During the execution of the method, there will be various bytecode instructions to write and extract contents to the Operand stack, that is, stack-in / out-stack operations. For example, when doing arithmetic operations, it is done through the Operand stack, or when other methods are called, parameters are passed through the Operand stack.

3. A reference to the runtime pool

A reference to the runtime constant pool of the class to which the current method belongs, to another constant class, or to a string in the string constant pool.

4. Method returns the address

After the execution of the method (either normally or with an exception), the program needs to return to the location where the method was called before the program can continue to execute, and the method return address holds some information to help restore the execution state of the upper-level method.

5. Dynamic link

Each stack frame contains a reference to the method to which the stack frame belongs in the runtime constant pool, which is held to support dynamic links during method calls.

Like program counters, the Java virtual machine stack is thread-private, has the same life cycle as threads, describes the memory model of Java method execution, and the data for each method call is passed through the stack.

There are two errors in the Java virtual machine stack:

StackOverFlowError: thrown when the depth of the thread request stack exceeds the maximum depth of the Java virtual machine stack.

OutOfMemoryError: if the Java virtual machine stack allows dynamic expansion, it is thrown when sufficient memory cannot be applied for when the stack is expanded.

The stack capacity of the most famous HotSpot virtual machine does not allow dynamic expansion, so there is no OutOfMemoryError on the HotSpot virtual machine.

03. Local method stack

The local method stack is similar to the Java virtual machine stack, except that the local method stack executes local methods, that is, methods decorated with the native keyword.

In the HotSpot virtual machine, there is no distinction between the local method stack and the Java virtual machine stack.

04, heap

A heap is an area of memory shared by all threads, created when the Java virtual machine starts, and is used to store objects (arrays are also objects).

In the past, "almost" all objects in Java were allocated in the heap, but with the development of JIT (Just-In-Time) compiler and the maturity of escape technology, all objects allocated to the heap gradually became less "absolute". Since JDK 7, the Java virtual machine has enabled escape analysis by default, which means that if the object reference in some method is not returned or used externally (that is, it does not escape), the object can allocate memory directly on the stack.

Briefly explain JIT and escape analysis.

Common compiled languages, such as CPU codes, usually compile the code directly into machine code to run. In order to realize the feature of "compile once, run everywhere", Java divides the compilation process into two parts. First, it will be compiled by javac into a general intermediate form-bytecode, and then the bytecode will be interpreted as machine code by the interpreter. So in terms of performance, Java may not be able to beat compiled languages such as C++.

In order to optimize the performance of Java, JVM introduces the JIT compiler outside the interpreter: when the program runs, the interpreter first plays a role, and the code can be executed directly. With the passage of time, the just-in-time compiler gradually plays a role, compiling more and more code to optimize the cost of code, in order to achieve higher execution efficiency. At this time, the interpreter can be used as a degraded means of compilation and running, and switch back to interpretation when there are problems with some unreliable compilation and optimization, so as to ensure that the program can run normally.

Escape analysis (Escape Analysis) is simply a technique in which the Hotspot virtual machine can analyze the scope of use of newly created objects and decide whether to allocate memory on the Java heap.

The heap is the main area managed by the Java garbage collector, so it is also called the GC heap (Garbage Collected Heap). From the perspective of garbage collection, because the garbage collector basically adopts the algorithm of generation-by-generation garbage collection, the heap can also be subdivided into the new generation and the old age. The new generation can also be subdivided into Eden space, From Survivor space, To Survivor space and so on. The purpose of further partitioning is to better reclaim memory, or to allocate memory faster.

The most common occurrence of heap is OutOfMemoryError error, which can be divided into the following forms:

OutOfMemoryError: GC Overhead Limit Exceeded: this error occurs when JVM spends too much time performing garbage collection and only a small amount of heap space is reclaimed.

Java.lang.OutOfMemoryError: Java heap space: this error is raised if there is not enough space in heap memory to hold the newly created object when creating a new object. It has nothing to do with the physical memory of this machine, but has something to do with the memory size of the virtual machine we configured!

05. Metaspace

With JDK 8, the original method zone (or, more accurately, permanent) was completely removed and replaced by metaspace.

Let's talk about the method area. The method area, like the heap, is a thread-shared area, which is used to store class information, constants, static variables, and compiled code after the toilet has been loaded by the Java virtual machine.

In some places, the method zone is also known as the permanent generation. But it can't be understood that way.

The Java virtual machine specification only defines the concept of a method zone and its role, but does not specify how to implement it. Then different Java virtual machines may have different implementations. Permanent generation is a form of implementation of the method area of HotSpot. In other words, permanent generation is only a concept in HotSpot, while the method zone is a definition, a specification in the Java virtual machine specification.

In other words, the relationship between the method zone and the permanent generation is like the relationship between the interface and the class in Java, which implements the interface.

There is also a very important part of the method area, that is, the runtime constant pool. When talking about class files, it is mentioned that every class file has a constant pool for string constants, class and interface names, field names, constants, and so on. The running constant pool corresponds to the constant pool of the class file one by one, and it is built through the constant pool in the class file.

Prior to JDK 7, the runtime constant pool contained a string constant pool, all in the method area.

With JDK 7, the string constant pool is taken out of the method area and placed on the heap, and everything else in the runtime constant pool is still in the method area.

With JDK 8, HotSpot removes the permanent generation, which means that the method zone no longer exists and is replaced by metaspace. This means that the string constant pool is in the heap, and the runtime constant pool runs to metaspace.

Let's talk about why the permanent generation (PermGen) or method area is replaced with a metaspace (MetaSpace).

If the permanent generation is placed in the Java virtual machine, it will be limited by the memory size of the Java virtual machine, while the metaspace uses local memory, which is free from the memory limit of the Java virtual machine.

In JDK 8, the JRockit virtual machine was integrated into HotSpot, but there is no concept of permanent generation in JRockit, so there is no need for the new HotSpot to open up a space as a permanent generation.

For us Java programmers, we don't need to be as concerned about memory leaks and spills all the time as programmers do, but in practice, these two problems occur quite frequently, especially in the case of multi-thread concurrency. If you don't understand how the Java virtual machine manages memory, you may be at a loss if you encounter problems.

After reading this, the article "how to allocate memory areas in Java virtual machines" has been introduced. If you want to master the knowledge points of this article, you still need to practice and use it yourself. If you want to know more about related articles, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.