JDK-8031967 : For some sources compiler compiles for ever
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8,8u5
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-01-16
  • Updated: 2020-11-12
  • Resolved: 2014-05-30
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 8 JDK 9
8u20Fixed 9 b16Fixed
Related Reports
Duplicate :  
JDK-8038492 - javac extremly slow
Relates :  
JDK-8038492 - javac extremly slow
Relates :  
JDK-8056984 - Exception in compiler: java.lang.AssertionError: isSubClass T
Relates :  
JDK-8056014 - Type inference may be skipped for a complex receiver generic method in a parameter position
Relates :  
JDK-8256290 - javac/lambda/T8031967.java fails with StackOverflowError on x86_32
Sub Tasks
JDK-8039772 :  
javac, remove AST modifications in Attr - Resolved
Description
The attached source file takes the javac 2s to compile on JDK 7u45. It takes 80s on JDK 8. The file is file from real life - a user of the IDE was trying to edit his source code.

Although the compiler finishes I consider this a crash since it effectively takes so much time that it is like not finishing at all. Moreover as we use the compiler inside NetBeans IDE the compiler in such case eats  all memory and our whole IDE dies because of that.

There is no workaround on our side - we cannot catch some exception or something. Also for the command line use of the javac - there might be cases (quite common in fact) that the compiler will not finish.

Hence marking the problem as P2.

Here is the simple repro test on my machine (using the attached file):

~/Downloads$date ; /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/javac inventorymgr/AddItem.java ; date
Thu Jan 16 09:48:26 CET 2014
Thu Jan 16 09:48:28 CET 2014
~/Downloads$date ; /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/javac inventorymgr/AddItem.java ; date
Thu Jan 16 09:49:09 CET 2014
Thu Jan 16 09:50:29 CET 2014
Comments
AutoVerify: Tests ran fine for JDK9-b16
27-06-2014
Release team: Approved for deferral.
21-01-2014
Agreed this is high priority to fix for the first available 8-update release. But first, we need a fix we are comfortable with.
17-01-2014
I respectfully disagree that the code is not common. I expect quite some number of duplicates especially from people having generated UI code. If this happens to users we will probably recommend them to revert to using -source 1.7. And I don't think we will be the only IDE whose users will be bitten by this ... Its not just GUI, its also HTML, XML generator libraries and possible generators for them. Check for example http://dom4j.sourceforge.net/dom4j-1.6.1/guide.html section "Creating a new XML document". Or http://jakarta.apache.org/ecs/index.html - see API for creating a HTML document. Or http://rendersnake.org/examples.html All these recommend people to write "Code with many levels of embedding of method invocations". I would vote for a fix to go at least into 8u20.
17-01-2014
8-defer-sqe-ok: This regression has been here a while and can be seen to have been caused by putbacks in b66 (up thru b65 was okay).
17-01-2014
8-defer-request justification: Code with many levels of embedding of method invocations is not very common (even though it can be for example produced by tools like UI designers, which is the case of the attached file). The proper fix for this problem will require deeper and longer investigation and is likely to be complex and risky. So we would like to ask for deferral to 9 (possibility of a backport to an 8 update would depend on the nature of the fix).
17-01-2014
From what I can tell, this is caused by several embedded speculative attributions. Each of these speculative attributions runs in several rounds, and the embedded speculative attributions run again and again in these rounds, leading ultimately (to my knowledge) in exponential processing time with the depth of the speculative attributions. I've attached a simple generator, that generates embedded method invocations, which can be used to check behavior of different embedding levels.
16-01-2014