Escape analysis

Short description: Determination of the dynamic scope of pointers

In compiler optimization, escape analysis is a method for determining the dynamic scope of pointers - where in the program a pointer can be accessed. It is related to pointer analysis and shape analysis.

When a variable (or an object) is allocated in a subroutine, a pointer to the variable can escape to other threads of execution, or to calling subroutines. If an implementation uses tail call optimization (usually required for functional languages), objects may also be seen as escaping to called subroutines. If a language supports first-class continuations (as do Scheme and Standard ML of New Jersey), portions of the call stack may also escape.

If a subroutine allocates an object and returns a pointer to it, the object can be accessed from undetermined places in the program - the pointer has "escaped". Pointers can also escape if they are stored in global variables or other data structures that, in turn, escape the current procedure.

Escape analysis determines all the places where a pointer can be stored and whether the lifetime of the pointer can be proven to be restricted only to the current procedure and/or thread.

## Contents

* 1 Optimizations
* 2 Practical considerations
* 3 Example (Java)
* 4 Examples (Scheme)
* 5 See also
* 6 References

## Optimizations

A compiler can use the results of escape analysis as a basis for optimizations:[1]

* Converting heap allocations to stack allocations.[2] If an object is allocated in a subroutine, and a pointer to the object never escapes, the object may be a candidate for stack allocation instead of heap allocation. In garbage-collected languages this can reduce how often the collector needs to run.
* Synchronization elision. If an object is found to be accessible from one thread only, operations on the object can be performed without synchronization.
* Breaking up objects or scalar replacement.[3] An object may be found to be accessed in ways that do not require the object to exist as a sequential memory structure. This may allow parts (or all) of the object to be stored in CPU registers instead of in memory.

## Practical considerations

In object-oriented programming languages, dynamic compilers are particularly good candidates for performing escape analysis. In traditional static compilation, method overriding can make escape analysis impossible, as any called method might be overridden by a version that allows a pointer to escape. Dynamic compilers can perform escape analysis using the available information on overloading, and re-do the analysis when relevant methods are overridden by dynamic code loading.[1]

The popularity of the Java programming language has made escape analysis a target of interest. Java's combination of heap-only object allocation, built-in threading, the Sun HotSpot dynamic compiler, and OpenJ9's just-in-time compiler (JIT) creates a candidate platform for escape analysis related optimizations (see Escape analysis in Java). Escape analysis is implemented in Java Standard Edition 6. Some JVMs support a stronger variant of escape analysis called partial escape analysis that makes scalar replacement of an allocated object possible even if the object escapes in some paths of a function.[4]

## Example (Java)

class Main {
public static void main(String[] args) {
example();

public static void example() {
Foo foo = new Foo(); //alloc
Bar bar = new Bar(); //alloc
bar.setFoo(foo);

class Foo {}

class Bar {
private Foo foo;
public void setFoo(Foo foo) {
this.foo = foo;

In this example, two objects are created (commented with alloc), and one of them is given as an argument to a method of another. The method `setFoo()` stores a reference to a received Foo object. If the Bar object was on the heap then the reference to Foo would escape. But in this case a compiler can determine, with escape analysis, that the Bar object itself does not escape the invocation of `example()`. As a result, the reference to Foo cannot escape either, and the compiler can safely allocate both objects on the stack.

## Examples (Scheme)

In the following example, the vector p does not escape into g, so it can be allocated on the stack and then removed from the stack before calling g.

(define (f x)
(let ((p (make-vector 10000)))
(fill-vector-with-good-stuff p)
(g (vector-ref p 7023))))

If, however, we had

(define (f x)
(let ((p (make-vector 10000)))
(fill-vector-with-good-stuff p)
(g p)))

then either p would need to be allocated on the heap or (if g is known to the compiler when f is compiled, and behaves well) allocated on the stack in such a fashion that it can remain in place when g is called.

If continuations are used to implement exception-like control structures, escape analysis can often detect this to avoid having to actually allocate a continuation and copy the call stack into it. For example, in

;;Reads scheme objects entered by the user. If all of them are numbers,
;;returns a list containing all of them in order. If the user enters one that
;;is not a number, immediately returns #f.
(define (getnumlist)
(call/cc (lambda (continuation)
(define (get-numbers)
(let ((next-object (read)))
(cond
((eof-object? next-object) '())
((number? next-object) (cons next-object (get-numbers)))
(else (continuation #f)))))
(get-numbers))))

escape analysis will determine that the continuation captured by call/cc doesn't escape, so no continuation structure needs to be allocated, and invoking the continuation by calling continuation can be implemented by unwinding the stack.

## See also

* Alias analysis
* Pointer analysis
* Shape analysis

## References

1. ↑ 1.0 1.1 T. Kotzmann and H. Mössenböck, “Escape analysis in the context of dynamic compilation and deoptimization,” in Proceedings of the 1st ACM/USENIX international conference on Virtual execution environments, New York, NY, USA, 2005, pp. 111–120.
2. ↑ Blanchet, Bruno (November 2003). "Escape Analysis for JavaTM: Theory and Practice". ACM Transactions on Programming Languages and Systems 25 (6): 713–775. doi:10.1145/945885.945886. ISSN 0164-0925.
3. ↑ Kotzmann, Thomas; Mössenböck, Hanspeter (March 2007). "Run-Time Support for Optimizations Based on Escape Analysis". International Symposium on Code Generation and Optimization (CGO'07). pp. 49–60. doi:10.1109/CGO.2007.34. ISBN 978-0-7695-2764-2.
4. ↑ Stadler, Lukas; Würthinger, Thomas; Mössenböck, Hanspeter (2014). "Partial Escape Analysis and Scalar Replacement for Java". Proceedings of Annual IEEE/ACM International Symposium on Code Generation and Optimization - CGO '14. pp. 165–174. doi:10.1145/2581122.2544157. ISBN 9781450326704.

* v
* t
* e

Compiler optimizations

Basic block|

* Peephole optimization

Loop optimization|

* Induction variable
* Strength reduction
* Loop fusion
* Loop inversion
* Loop interchange
* Loop-invariant code motion
* Loop nest optimization
* Loop unrolling
* Loop splitting
* Loop unswitching
* Software pipelining
* Automatic parallelization

Data-flow analysis|

* Common subexpression elimination
* Constant folding
* Induction variable recognition and elimination
* Dead store elimination
* Use-define chain
* Live variable analysis
* Available expression

SSA-based|

* Global value numbering
* Sparse conditional constant propagation

Code generation|

* Register allocation
* Instruction selection
* Instruction scheduling
* Rematerialization

Functional|

* Tail call elimination
* Deforestation

Global|

* Interprocedural optimization

Other|

* Bounds-checking elimination
* Compile-time function execution
* Dead code elimination
* Inline expansion
* Jump threading

Static analysis|

* Alias analysis
* Pointer analysis
* Shape analysis
* Escape analysis
* Array access analysis
* Dependence analysis
* Control flow analysis
* Data-flow analysis

0.00

(0 votes)

Original source: https://en.wikipedia.org/wiki/Escape analysis. Read more

|

Retrieved from "https://handwiki.org/wiki/index.php?title=Escape_analysis&oldid=4158183"
*[v]: View this template
*[t]: Discuss this template
*[e]: Edit this template