Escape Analysis (EA) is a very important technique that the just-in-time Java compiler can use to analyze the scope of a new object and decide whether it might not be allocated to Java heap space.

Many resources available on the Internet say that EA allows objects to be allocated on the method stack. While, technically, they could be allocated on the stack, they are not in the current version of Java 8.

The official Java documentation says:

“It does not replace a heap allocation with a stack allocation for non-globally escaping objects.”

Fortunately, Escape Analysis allows the JIT compiler to replace a new object by unpacking its fields onto the stack, effectively performing kind of stack allocation. So, instead of creating every single object on Java heap space, some of them can be “exploded” and the fields kept on the method stack or even in CPU registers instead of Java heap space. This is a very important performance optimization because stack allocation and de-allocation are much faster than heap space allocation. But which objects can be kept like that?

Escape States

There are three escape states objects can be in:

• NoEscape – when the object cannot be visible outside the current method and thread.
• ArgEscape – when the object is passed as an argument to a method but cannot otherwise be visible outside the method or by other threads.
• GlobalEscape – when the object can escape the method or the thread. What that basically means is that objects with the GlobalEscape state will be visible outside methods/threads, for instance, when the object is returned from the method or assigned to a static field.

The optimization mentioned before can be easily applied to objects that have been classified during Escape Analysis as NoEscape.

public String getCarDescription() {
    Car car = new Car();
    String description = car.generateDescription();
    return description;
}

In the snippet above, car is an example of object with NoEscape state – it is not visible nor accessible outside getCarDescription() method.

Locking and Synchronization

Additionally, the JIT compiler can remove some locking and memory synchronization overhead for NoEscape and ArgEscape objects because these objects are only visible from the calling thread. A good example is an old synchronized StringBuffer in which synchronization can be removed if a buffer object is classified as NoEscape or ArgEscape.

Escape Analysis is enabled by default with the server compiler. To disable it, use the -XX:-DoEscapeAnalysis JVM flag.