This post looks at escape analysis, in particular how long it takes for the jvm to effect escape analysis in a running program. I make some observations but don’t have all the explanation at this point.
By way of introduction let’s take a detour to look at a little known and even less used flag (which we’ll see is a good thing) in the jvm, -Xcomp.
The behaviour for this flag is defined in the jvm documentation as:
-Xcomp Forces compilation of methods on first invocation. By default, the Client VM (-client) performs 1,000 interpreted method invocations and the Server VM (-server) performs 10,000 interpreted method invocations to gather information for efficient compilation. Specifying the -Xcomp option disables interpreted method invocations to increase compilation performance at the expense of efficiency.
At first sight this seems to be an excellent option. A shortcut to warming up the jvm through 10,000 cycles – we can get the code to compile straight away. Shouldn’t we always enable this option by default?
But the documentation does warn that this will be ‘at the expense of efficiency’.
The jvm learns about code behaviour in the 10,000 warmup cycles so that when it comes to compiling it compiles in the most efficient way possible. Compiling the code right away will mean that yes the code is indeed compiled but that the compiled code may not be the most efficient. You can read more about it in this blogpost – but that’s not really the subject of this post.
Something else that doesn’t happen if you use -Xcomp is escape analysis. This is actually rather surprising as the jvm shouldn’t need to learn about whether escape analysis is possible by running the program. This should be evident by a static analysis of the code.
Have a look at this code (I was inspired by the ideas in this blog):
import java.io.IOException;
import java.util.Optional;
/**
* Created by daniel on 17/12/2015.
*/
public class Test {
private static String NAME;
public static void main(String[] args)throws IOException {
new Test().test();
}
public void test() throws IOException {
Name name = new Name("Steven");
int iterations = 1_000_000;
for(;;){
countOptional(name, iterations);
System.out.println("Press any key to continue");
System.in.read();
}
}
private static void countOptional(Name name, int iterations) {
for (int i = 0; i < iterations; i++) {
NAME = name.getOptionalName().get();
}
System.out.println(iterations + " optional iterations " + NAME);
}
class Name {
private final String name;
public Name(String name) {
this.name = name;
}
public Optional<String> getOptionalName() {
return Optional.ofNullable(name);
}
}
}We need to make sure that the program runs without a gc (I suggest these flags):
-verbosegc -Xmx4g -Xms4g
When the program waits for input carry out a heap dump to see how many Optional object have been created. Then hit any key to resume the program.
To perform a heap dump first run jps to identify the pid of the program then run:
jmap -histo pid | head
Do this once without the -Xcomp flag and once with -Xcomp flag.
Without the -Xcomp flag
After first iteration:
After second iteration:
All subsequent iterations are the same no further objects are created:
There’s clearly escape analysis kicking in after 234k iterations – not sure why it should take so long, usually (for example with compiling code) 10k iterations is enough? Also in the second iteration it creates another ~400k objects before escape analysis kick in which is also a bit mysterious.
With the -Xcomp flag
After the first iteration:
After the second iteration:
After each iteration the number of Optional objects goes up by 1m.
Summary
- -Xcomp is a switch that should almost certainly never be used in production. I can imagine some scenarios where you might want to play around with disabling the interpreter but those would be very specific edge cases.
- It seems to take at least 200K iteration for escape analysis to be effective. So you need to allow longer than the 10k iterations for a full warm up.
- There is also another phase where after escaping out objects it seems to need to do this again. This needs further understanding.
- If you slow the program down a bit by doing some work in between the calls to create the Optional the number of objects reduces. For example I found that a call to Math.sin reduces the Optional objects by about 50%.
| Reference: | How long does it take the jvm to effect escape analysis? Maybe longer than you think. from our JCG partner Daniel Shaya at the Rational Java blog. |
