How to understand escape in Java

In the Java compilation system, the process of turning a Java source code file into a computer-executable machine instruction requires two stages of compilation. The first stage is to convert the .java file into a .class file. The second stage of compilation is the process of converting .class into machine instructions.

The first section of compilation is the javac command.

In the second compilation stage, the JVM interprets the bytecode and translates it into corresponding machine instructions, reads it in one by one, and interprets the translation one by one. Obviously, after interpretation and execution, its execution speed will inevitably be much slower than the executable binary bytecode program. This is the function of the traditional JVM interpreter (Interpreter). In order to solve this efficiency problem, JIT (just in time compilation) technology was introduced.

After the introduction of JIT technology, Java programs are still interpreted and executed through the interpreter. When the JVM finds that a certain method or code block is running particularly frequently, it will consider it to be "Hot Spot Code". Then JIT will translate part of the "hot code" into machine code related to the local machine, optimize it, and then cache the translated machine code for next use.

Since I have already introduced the content of JIT compilation and hotspot detection in my in-depth analysis of Java compilation principles, I will not go into details here. This article mainly introduces the optimization in JIT. One of the most important aspects of JIT optimization is escape analysis.

Escape analysis

Regarding the concept of escape analysis, you can refer to the fact that not all objects and arrays allocate memory on the heap. One article, here is a brief review:

The basic behavior of escape analysis is to analyze the dynamic scope of the object: when an object is defined in a method, it may be referenced by an external method, such as being passed to other places as a call parameter, which is called method escape.

For example, the following code:

public static StringBuffer craeteStringBuffer(String s1, String s2) {

StringBuffer sb = new StringBuffer();

sb.append(s1);

sb.append(s2);

Return sb;

}

public static String createStringBuffer(String s1, String s2) {

StringBuffer sb = new StringBuffer();

sb.append(s1);

sb.append(s2);

Return sb.toString();

}

The sb in the first code escapes, but the sb in the second code does not escape.

Using escape analysis, the compiler can optimize the code as follows:

1. Synchronization is omitted. If an object is found to be accessible only from one thread, synchronization may not be considered for operations on this object.

2. Convert heap allocation to stack allocation. If an object is allocated in a subroutine, so that the pointer to the object never escapes, the object may be a candidate for stack allocation rather than heap allocation.

3. Separate objects or scalar replacement. Some objects may not need to exist as a continuous memory structure to be accessed, so part (or all) of the object may not be stored in memory, but stored in CPU registers.

When Java code is running, you can specify whether to enable escape analysis through JVM parameters,

-XX: DoEscapeAnalysis: Indicates turning on escape analysis

-XX:-DoEscapeAnalysis: Indicates turning off escape analysis. Starting from jdk 1.7, escape analysis has been started by default. If you want to turn it off, you need to specify -XX:-DoEscapeAnalysis

Synchronization omitted

When dynamically compiling a synchronized block, the JIT compiler can use escape analysis to determine whether the lock object used by the synchronized block can only be accessed by one thread and has not been released to other threads.

If the lock object used by the synchronized block is confirmed to be only accessible by one thread through this analysis, the JIT compiler will desynchronize this part of the code when compiling the synchronized block. This process of canceling synchronization is called synchronization omission, also called lock elimination.

Such as the following code:

public void f() {

Object hollis = new Object();

synchronized(hollis) {

System.out.println(hollis);

}

}

The hollis object is locked in the code, but the life cycle of the hollis object is only in the f() method and will not be accessed by other threads, so it will be optimized during the JIT compilation phase. Optimized to:

public void f() {

Object hollis = new Object();

System.out.println(hollis);

}

Therefore, when using synchronized, if the JIT finds that there is no thread safety problem after escape analysis, it will eliminate the lock.

Scalar replacement

Scalar refers to a data that cannot be broken down into smaller data. The primitive data type in Java is scalar. In contrast, data that can be decomposed is called an aggregate. An object in Java is an aggregate because it can be decomposed into other aggregates and scalars.

In the JIT stage, if it is found through escape analysis that an object will not be accessed by the outside world, then after JIT optimization, the object will be disassembled into several member variables contained in it and replaced. This process is scalar replacement.

public static void main(String[] args) {

alloc();

}

private static void alloc() {

Point point = new Point(1,2);

System.out.println("point.x=" point.x "; point.y=" point.y);

}

class Point{

private int x;

private int y;

}

In the above code, the point object does not escape the alloc method, and the point object can be disassembled into scalars. Then, JIT will not directly create the Point object, but directly use two scalars int x and int y to replace the Point object.

The above code, after scalar replacement, will become:

private static void alloc() {

int x = 1;

int y = 2;

System.out.println("point.x=" x "; point.y=" y);

}

It can be seen that after the escape analysis of the aggregate quantity Point, it was found that it did not escape, so it was replaced by two aggregate quantities. So what are the benefits of scalar substitution? That is, it can greatly reduce the heap memory usage. Because once there is no need to create objects, there is no need to allocate heap memory.

Scalar substitution provides a good basis for allocation on the stack.

Allocation on stack

In the Java virtual machine, it is common knowledge that objects are allocated memory in the Java heap. However, there is a special case, that is, if after escape analysis it is found that an object does not have an escape method, it may be optimized into allocation on the stack. This eliminates the need to allocate memory on the heap and eliminate the need for garbage collection.

For a detailed introduction to allocation on the stack, please refer to Not all objects and arrays allocate memory on the heap. .

Here, I would like to briefly mention that in existing virtual machines, allocation on the stack is not really implemented, and objects and arrays are not all allocated on the heap. In our example, the object is not allocated on the heap, it is actually implemented by scalar replacement.

Escape analysis is not mature

The paper on escape analysis was published in 1999, but it was not implemented until JDK 1.6, and this technology is not very mature yet.

The fundamental reason is that there is no guarantee that the performance consumption of escape analysis will be higher than its consumption. Although escape analysis can do scalar substitution, stack allocation, and lock elimination. However, escape analysis itself also requires a series of complex analyses, which is actually a relatively time-consuming process.

An extreme example is that after escape analysis, it is found that no object does not escape. Then the process of escape analysis is wasted.

Although this technology is not very mature, it is also a very important means in just-in-time compiler optimization technology.

The above is the detailed content of How to understand escape in Java. For more information, please follow other related articles on the PHP Chinese website!