Talk:Escape analysis

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

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.

Is this not only the case for languages with dynamic loading of classes. If a language knows every used class at compile-time it should be able to do escape analysis.

Sample algorithms?[edit]

This page doesn't say anything about ways escape analysis may be performed. Dfeuer (talk) 17:32, 12 June 2012 (UTC)[reply]

The Java Exampe should be changed[edit]

I think that the current Java example is not appropriate for Wikipedia, becase it contains potentialy unsafe but legal Java code, e.g. passing this reference to a method inside a constructor. And it seems that the whole article is ambiguous about what is an escape. Is it just passing a pointer to a subroutine, or does a pointer escape only if it survives beyond the life time of the stack frame of the function in question. In the current example a reference is passed to a method, and the code that is executed in turn does not save the reference on the heap or in a static variable, so it does not survive beyond the lifetime of the constructor's stack frame. If that wasn't a constructor but a method that created an instance of A, and passed it to doSomething, the compiler could alocate the A object on the stack. The example should be changed in that direction (it should show successfull escape analysis). The compiler could not perform escape analysis on the call to doSomething only if it didn't have access to the implementation, but the JVM JIT compiler certainly has access to it, even if it is in an external library. So if you agree and no comments land on this page in any resonable amount of time, I will proceed with the changes. --Ivan90bg (talk) 21:44, 20 December 2012 (UTC)[reply]