Specifies the lifetime and accessability of object instance. This is classically used for compiler optimizations such as scalar replacement, stack allocation or removal of synchronization. However, other usages such as finding bugs or helping to identify immutable data-structures are also supported.

Definitions in the Literature

Choi et al. [1] describe two predicates that can be used to describe the properties relevant to escape information.

"Let O be an object instance and M be a method invocation. O is said to escape M, denoted as Escapes(O, M), if the lifetime of O may exceed the lifetime of M."

"Let O be an object instance and T be a thread (instance). O is said to escape T, again denoted as Escapes(O, T), if another thread, T’ != T, may access O."

Furthermore it holds that "For any object O, !Escapes(O, M) implies !Escapes(O, T), where method M is invoked in thread T." [1]

In contrast to this, Kotzmann and Mössenböck [2] describe the escape of an object with the access to this object from other methods or threads.

Definition

This EscapeProperty combines both concepts and is more specific about the reason why an object escapes to facilitate comprehension of the results.

In the following, we provide further details about the different escape properties:

NoEscape refers to the property of an object instance O created in method M for that it lifetime ends with the lifetime of M and no other method than M has access to O. This implies that there is no method M' != M that can access O (at least when disregarding reflection and native code). Objects with this property can be allocated at the stack or even scalar-replaced [2].

An object instance O created in method M and thread T has the property EscapeInCallee, if its lifetime does not exceed the lifetime of M but M passes O as a parameter to a method which does not let O escape any further then EscapeInCallee. This implies that only M and methods M' that are (transitively) called by M have access to O. For objects that have the property EscapeInCallee no synchronization is needed and they can be allocated on the stack.

For objects O, created in method M and thread T, whose lifetime exceeds its method of creation M and is (therefore) accessible by other methods, we provide seven different properties. For all of them we assume that M and all methods called by M do not let O escape the thread T. But it is not guaranteed that O will not escape T via a caller of M. The properties differ in the reason why the lifetime of O exceeds the lifetime of M. In case of EscapeViaReturn O is returned by M. If O has an exception type and is thrown in M, it has the property EscapeViaAbnormalReturn. For both of them it has no consequences if O escapes T via a caller of M. This is, because the execution ends with the (abnormal) return of O. All synchronization mechanisms inside of M or callees of M can be removed. The property EscapeViaParameter describes objects that gets assigned to a parameter of its method of creation (M). If O gets assigned to p.f for a parameter p of M, it could be the case that the actual parameter of p already escaped T. In this case O would also escape T directly via this assignment. Therefore no synchronization for O can be removed. As it could be also the case that O gets assigned to a parameter and returned by M, there are also properties representing the combinations of this kind of escapes. They are EscapeViaParameterAndAbnormalReturn, EscapeViaParameterAndReturn, EscapeViaNormalAndAbnormalReturn and EscapeViaParameterAndNormalAndAbnormalReturn.

An object instance O created in method M and thread T has the property GlobalEscape, if its lifetime may exceed the lifetime of T (and another thread T'! = T gets access to O). For example, this is the case if O gets assigned to a static field (EscapeViaStaticField but also if assigned to a field of an object that has also GlobalEscape as property (EscapeViaHeapObject). Objects that have the property GlobalEscape have to be allocated on the heap and synchronization mechanisms can not be removed/proper synchronization is required if the object is accessed concurrently – the latter may be the goal of static analyses that find concurrency bugs). If the reason for the global escape is unspecified the case class GlobalEscape is used.

The property values are partially ordered and form a lattice. The binary relation of the order is called lessOrEqualRestrictive and describes the restrictiveness of the scope in, which objects exists. The most restrictive (top) value is NoEscape and the least restrictive (bottom) one is GlobalEscape. A dot graph of the lattice can be found under br/src/main/resources/org/opalj/fpcf/properties.

Algorithms are free to over approximate this property, i.e., for object instance O with actual property P it is okay to say O has property P' if P > P' (or in other words, P' is less restrictive than P).

If they simply don't know the actual property they should use AtMost(NoEscape). If we know that the actual property is at most (i.e. not NoEscape), AtMost(EscapeInCallee) should be used. The same holds for every other non-bottom property. E.g. AtMost(EscapeViaParameter) should be used if we know that the actual property is at most EscapeViaParameter (i.e. neither NoEscape nor EscapeInCallee.

org.opalj.ai.DefinitionSiteLike and org.opalj.br.analyses.VirtualFormalParameter are generally used as org.opalj.fpcf.Entity in combination with this property.

VirtualMethodEscapeProperty provides a wrapper of this property addressing aggregated escape information for parameters of methods in a type hierarchy.

[1] Choi, Jong-Deok, Manish Gupta, Mauricio Serrano, Vugranam C. Sreedhar, and Sam Midkiff. "Escape Analysis for Java." In Proceedings of the 14th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, 1–19. OOPSLA ’99. New York, NY, USA: ACM, 1999.

[2] Kotzmann, Thomas, and Hanspeter 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, 111–120. VEE ’05. New York, NY, USA: ACM, 2005.