As far as I know the JVM uses escape analysis for some performance optimisations like lock coarsening and lock elision. I\'m interested if there is a possibility for the JVM
Escape analysis is really nice, but it is not a complete get of jail free card. if you have a dynamically sized collection inside of an object, the escape analysis will NOT switch from heap to stack. For example:
public class toEscape {
public long l;
public List<Long> longList = new ArrayList<Long>();
}
Even if this object is created in a method and absolutely does NOT escape from a syntactic point of view, the compiler will not mark this for escape. I suspect because that longList is not really bounded in size from a pure syntactic perspective and it could blow your stack potentially. Thus I believe it takes a pass on this case. I experimented with this where the longList was empty and still it caused collections in a simple micro benchmark.
With this version of java -XX:+DoEscapeAnalysis results in far less gc activity and 14x faster execution.
$ java -version
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)
$ uname -a
Linux xxx 2.6.18-4-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686 GNU/Linux
Without escape analysis,
$ java -server -verbose:gc EscapeAnalysis|cat -n
1 start
2 [GC 896K->102K(5056K), 0.0053480 secs]
3 [GC 998K->102K(5056K), 0.0012930 secs]
4 [GC 998K->102K(5056K), 0.0006930 secs]
--snip--
174 [GC 998K->102K(5056K), 0.0001960 secs]
175 [GC 998K->102K(5056K), 0.0002150 secs]
176 10000000
With escape analysis,
$ java -server -verbose:gc -XX:+DoEscapeAnalysis EscapeAnalysis
start
[GC 896K->102K(5056K), 0.0055600 secs]
10000000
The execution time reduces significantly with escape analysis. For this the loop was changed to 10e9 iterations,
public static void main(String [] args){
System.out.println("start");
for(int i = 0; i < 1000*1000*1000; ++i){
Foo foo = new Foo();
}
System.out.println(Foo.counter);
}
Without escape analysis,
$ time java -server EscapeAnalysis
start
1000000000
real 0m27.386s
user 0m24.950s
sys 0m1.076s
With escape analysis,
$ time java -server -XX:+DoEscapeAnalysis EscapeAnalysis
start
1000000000
real 0m2.018s
user 0m2.004s
sys 0m0.012s
So with escape analysis the example ran about 14x faster than the non-escape analysis run.
I don't think it does escape analysis for stack allocation. example:
public class EscapeAnalysis {
private static class Foo {
private int x;
private static int counter;
public Foo() {
x = (++counter);
}
}
public static void main(String[] args) {
System.out.println("start");
for (int i = 0; i < 10000000; ++i) {
Foo foo = new Foo();
}
System.out.println(Foo.counter);
}
}
with -server -verbose:gc -XX+DoEscapeAnalysis
:
start [GC 3072K->285K(32640K), 0.0065187 secs] [GC 3357K->285K(35712K), 0.0053043 secs] [GC 6429K->301K(35712K), 0.0030797 secs] [GC 6445K->285K(41856K), 0.0033648 secs] [GC 12573K->285K(41856K), 0.0050432 secs] [GC 12573K->301K(53952K), 0.0043682 secs] [GC 24877K->277K(53952K), 0.0031890 secs] [GC 24853K->277K(78528K), 0.0005293 secs] [GC 49365K->277K(78592K), 0.0006699 secs] 10000000
Allegedly JDK 7 supports stack allocation.