JDK-8048838 : type inference performance regression
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8u20,8u40,9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-06-30
  • Updated: 2015-06-04
  • Resolved: 2015-03-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b56Fixed
Related Reports
Blocks :  
JDK-8051946 - JEP 215: Tiered Attribution for javac
Blocks :  
JDK-8032360 - javac, speculative attribution refactoring
Relates :  
JDK-8055984 - type inference exponential compilation performance
Relates :  
JDK-8029002 - javac should take multiple upper bounds into account in incorporation
Description
Time of compilation of attached source is increased by 10-30 times on 8u20 and 9 compared with 8:

  14 sec  jdk8, solaris-x64  
 150 sec  jdk9, solaris-x64  (time increase: x11)
 120 sec  jdk8, solaris-sparcv9 
4020 sec  jdk9, solaris-sparcv9 (time increase: x33)
Comments
Raised priority as this affects the type annotations work - see JDK-8031744
02-03-2015
8a exclude list is not updated with JCK bug, that's why I added tck-red. http://jre.us.oracle.com/java/re/jck/8a/nightly/extra/latest/jtx/jck8amaster.jtx : lang/INFR/infr066/infr06603m022/infr06603m022.html JDK-8048838 placeholder lang/INFR/infr066/infr06603m022/infr06603m022_rt.html JDK-8048838 placeholder lang/INFR/infr066/infr06603m03/infr06603m03.html JDK-8048838 placeholder lang/INFR/infr066/infr06603m03/infr06603m03_rt.html JDK-8048838 placeholder lang/INFR/infr066/infr06603m131/infr06603m131.html JDK-8048838 placeholder lang/INFR/infr066/infr06603m131/infr06603m131_rt.html JDK-8048838 placeholder lang/INFR/infr066/infr06603m232/infr06603m232.html JDK-8048838 placeholder lang/INFR/infr066/infr06603m232/infr06603m232_rt.html JDK-8048838 placeholder
30-10-2014
This is not a tck-red per the Leonid's comment below: Leonid Arbouzov wrote: > > The tests are excluded in b16 as you can see: > > http://jre.us.oracle.com/java/re/jck/8a/promoted/fcs/b16/binaries/JCK-compiler-8a/tests/lang/INFR/infr066/infr066.html > > The test are excluded based on JCK issue: JCK-7303646
30-10-2014
infr06603m* tests take same time to compile on jdk8.0/8u20/9 so the regression is not related in this case - filed as a separate issue JDK-8055984
25-08-2014
Attaching infr06603m03.java, infr06603m131.java. Each of these sources compiles more than 10 minutes. These are new JCK tests on jls-18.3.1-200-A. BTW: however such code is quite unlikely to be created by human, it could possibly be generated by a code-generator.
17-07-2014
Yes it is exponential but the pattern is uncommon in real code.
02-07-2014
On solaris-x64 with jdk8u20: 50 bounds - 10 sec 100 bounds - 140 sec 200 bounds - 8200 sec Does this look more like exponential?
02-07-2014
This problem is related to the fact that the check described in 18.3.1. (Complementary Pairs of Bounds) is invoked a number of times that grows quadratically with the number of interdependent upper bounds. Since in this case there are 100 bounds, the check is called some 10000 times on each call of checkWithinBounds. While in principle it could be possible to tweak the routine to make it faster, in practice only small improvements would be observed - the real cause behind the performance regression is the addition of the check described in 18.3.1 - which was missing before 8u20. Downgrading to P4. I also did some experiment to evaluate the impact of JDK-8043893 on this problem - as that fix changed the routine a little bit to take into account the case where lub returned intersection types. No extra performance cost seems to be added by the tweaked routine: BEFORE 8043893 real 3m48.416s user 3m56.731s sys 0m0.939s AFTER 8043893 real 3m48.094s user 3m55.616s sys 0m0.906s So, the big performance spike is caused by JDK-8029002, which correctly adds a specified check.
01-07-2014