-
Bug
-
Resolution: Fixed
-
P3
-
8u40, 9
-
b83
-
x86_64
-
linux
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8142239 | emb-9 | Maurizio Cimadamore | P3 | Resolved | Fixed | team |
~/apps/jdk1.7.0_51/bin/java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
~/apps/jdk1.8.0_40/bin/java -version
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux se-185 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
See Test1.java as an example that shows the problem. It is very much stripped down from the original code, to showcase the problem.
The JDK 7 compiler compiles this very fast. JDK 8 compilers seem to perform exponentially more work, and compilation time blows up. This to me is a severe performance regression, making it practically impossible to perform runtime in-memory code compilation.
For 12 nested 'x' calls, as in Test1.java, this is the performance:
$ time ~/apps/jdk1.7.0_51/bin/javac Test1.java
real 0m0.380s
user 0m0.616s
sys 0m0.024s
$ time ~/apps/jdk1.8.0_40/bin/javac Test1.java
real 0m34.500s
user 0m39.698s
sys 0m0.172s
Changing the 12 nested 'x' calls to more nested 'x' calls leads me to conclude that an exponential amount of work is performed. Maybe multiple variants are tried for each call?
It should be noted that the Eclipse Luna JDT Java 8 compiler has no issues with this code, and compiles it very fast.
I looked, but could not find an existing bug report for this performance degradation. I did previously report a similar, but different performance issue, currently under review with Review ID:
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.util.LinkedHashMap;
import java.util.Map;
@SuppressWarnings("javadoc")
public class Test1 {
public static void main(String[] args) {
Map<Integer, String> a = x(x(x(x(x(x(x(x(x(x(x(x(
new LinkedHashMap<Integer, String>(),
1, "a"), 2, "b"), 3, "c"), 4, "d"),
5, "e"), 6, "f"), 7, "g"), 8, "h"),
9, "i"), 10, "j"), 11, "k"), 12, "l");
System.out.println(a);
}
@SuppressWarnings("unused")
public static <K, V> Map<K, V> x(Map<K, V> m, K k, V v) {
// Replaced actual code by dummy implementation.
return null;
}
}
---------- END SOURCE ----------
- backported by
-
JDK-8142239 Severe compiler performance regression Java 7 to 8 for nested method invocations
-
- Resolved
-
- duplicates
-
JDK-8151267 javac takes 5-6 minutes to compile a simple 50 line class
-
- Closed
-
-
JDK-8280873 Compile with long and deeply statement is prohibitively slow
-
- Closed
-
-
JDK-8077247 Exponential performance regression Java 8 compiler compared to Java 7 compiler
-
- Closed
-
-
JDK-8162704 deeply nested expression stumps the compiler-checking algorithm
-
- Closed
-
- is blocked by
-
JDK-8051946 JEP 215: Tiered Attribution for javac
-
- Closed
-
- relates to
-
JDK-8055984 type inference exponential compilation performance
-
- Resolved
-
-
JDK-8175794 Type inference regression after JDK-8078093
-
- Resolved
-
-
JDK-8077247 Exponential performance regression Java 8 compiler compared to Java 7 compiler
-
- Closed
-
-
JDK-8168480 Speculative attribution of lambda causes NPE in Flow
-
- Closed
-
-
JDK-8176714 javac is wrongly assuming that field JCMemberReference.overloadKind has been assigned to
-
- Closed
-
-
JDK-8147493 regression when type-checking unchecked method calls
-
- Closed
-
-
JDK-8147546 regression when type-checking generic calls inside nested declarations occurring in method context
-
- Closed
-
-
JDK-8154180 Regression: stuck expressions do not behave correctly
-
- Closed
-
-
JDK-8174249 Regression in generic method unchecked calls
-
- Closed
-