JDK-8021775 : compiler/8009761/Test8009761.java "Failed: init recursive calls: 51. After deopt 50"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,7u65,emb-8u6,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux_redhat_5.0
  • CPU: x86
  • Submitted: 2013-07-29
  • Updated: 2019-09-13
  • 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 9
9 b20Fixed
Related Reports
Relates :  
JDK-8048003 - test/compiler/8009761/Test8009761.java failed with: java.lang.RuntimeException: static java.lang.Object Test8009761.m3(boolean,boolean) not compiled
Relates :  
JDK-8009761 - Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates
Description
In 2013-07-25 RT_Baseline nightly

Test
compiler/8009761/Test8009761.java
failed with this output:

command: main -XX:CompileCommand=exclude,Test8009761::m2 -XX:-UseOnStackReplacement -XX:-BackgroundCompilation -Xss256K Test8009761
reason: User specified action: run main/othervm -XX:CompileCommand=exclude,Test8009761::m2 -XX:-UseOnStackReplacement -XX:-BackgroundCompilation -Xss256K Test8009761 
elapsed time (seconds): 7.902
----------System.out:(3/134)----------
CompilerOracle: exclude Test8009761.m2
### Excluding compile: static Test8009761::m2
Failed: init recursive calls: 51. After deopt 50
----------System.err:(0/0)----------
result: Failed. Execution failed: Execution failed
Comments
This failure mode was spotted in the 2014-04-30 RT_Baseline nightly: compiler/8009761/Test8009761.java This test failed due to "Failed: init recursive calls: 18. After deopt 17". This appears to be an instance of the following bug: JDK-8021775 compiler/8009761/Test8009761.java "Failed: init recursive calls: 51. After deopt 50" Added "9" to the "Affects Version/s" field.
01-05-2014
This is happening now on windows for the jdk9/hs/hotspot nightly testing: http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=471945.JAVASE.NIGHTLY.VM.Main_Baseline_product.2014-04-24-206 #section:main ----------messages:(3/332)---------- command: main -XX:CompileCommand=exclude,Test8009761::m2 -XX:-UseOnStackReplacement -XX:-BackgroundCompilation -Xss256K Test8009761 reason: User specified action: run main/othervm -XX:CompileCommand=exclude,Test8009761::m2 -XX:-UseOnStackReplacement -XX:-BackgroundCompilation -Xss256K Test8009761 elapsed time (seconds): 0.219 ----------System.out:(2/90)---------- CompilerOracle: exclude Test8009761.m2 Failed: init recursive calls: 26. After deopt 25
29-04-2014
ILW=MMM=P3
07-10-2013
SQE is ok to defer from JDK8
07-10-2013
8-defer-request: What the test does is: compile a method with an inlinee, force a deopt and checks that the stack size after the deoptimization is the same as it was before the compilation. there was a bug on sparc where deoptimization wouldn't restore the interpreter stack correctly and some stack space was wasted. When this happened, the "init recursive calls" and "After deopt" reported by the test would show a much bigger difference than 1 as in the current failure. I had problems making the test robust and had test bugs with this one in the past so it's quite possible it's a test bug. If it's not a test bug what the failure means is that there's a difference in the interpreter stack before and after the deopt. Because the difference reported by the test is small (1), this can only be a minor issue. Defer to JDK8u20
07-10-2013
P3 bug
01-10-2013
Again? Roland should know something about this.
29-07-2013
Moving from hotspot/runtime -> hotspot/compiler.
29-07-2013