This post follows on from the previous post about visualising JIT.
Let's start with a simple, silly main method:
Plotting the elapsed time in ns:
We can see that:
Up to about the 70th run it is running in the interpreter
Then it drops into C1 until 200
At 200 it optimises again into C2
At 600 it hits our curve ball and deoptimises the method.
Method eventually drops back in C2 at around 800.
Curve ball:
The compiler thought that our String curveBall was always going to be null and it added that into the compiler. However, when we set it to something other than null the compiler realised that it has made a wrong assumption and had to deoptimise that compiled method.
Let's start with a simple, silly main method:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
public static void main(String... args) { | |
String curveBall = null; | |
int count = 0; | |
for (int i =0; i <1000; i++) { | |
long startTime = System.nanoTime(); | |
for (int j = 0; j < 1000; j ++) { | |
count += j; | |
if (curveBall != null) { | |
System.out.println(curveBall); | |
curveBall = null; | |
} | |
} | |
if (i == 600) curveBall = "Throwing a curve ball!!!!"; | |
long endtime = System.nanoTime(); | |
System.out.printf("%d\n", endtime - startTime); | |
} | |
System.out.println(count); | |
} |
We can see that:
Up to about the 70th run it is running in the interpreter
Then it drops into C1 until 200
At 200 it optimises again into C2
At 600 it hits our curve ball and deoptimises the method.
Method eventually drops back in C2 at around 800.
Curve ball:
The compiler thought that our String curveBall was always going to be null and it added that into the compiler. However, when we set it to something other than null the compiler realised that it has made a wrong assumption and had to deoptimise that compiled method.
No comments:
Post a Comment