JDK-8181857 : MathPowTest::computeRow recompiles infinitely
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2015-12-01
  • Updated: 2017-06-12
  • Resolved: 2017-06-12
Related Reports
Relates :  
JDK-8134795 - Port fdlibm pow to Java
Description
When looking into whether we still need the Math.pow substitution on AMD64 after JDK-8134795 I saw that Graal recompiles one method over and over again:

$ java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -Djvmci.compiler=graal -XX:+BootstrapJVMCI MathPowTest
...
  77697 9793 %           MathPowTest::computeRow @ 10 (45 bytes)
  77697 9794 %           MathPowTest::computeRow @ 10 (45 bytes)
  77698 9795 %           MathPowTest::computeRow @ 10 (45 bytes)
  77698 9796 %           MathPowTest::computeRow @ 10 (45 bytes)
  77698 9797             MathPowTest::computeRow (45 bytes)
  77699 9798             MathPowTest::computeRow (45 bytes)
  77699 9799             MathPowTest::computeRow (45 bytes)
  77699 9800 %           MathPowTest::computeRow @ 10 (45 bytes)

The test case is attached to JDK-8134795.

This only happens if the substitution is disabled.
Comments
I agree with Tom's evaluation. Closing this as Won't Fix.
12-06-2017
I'm not sure we actually want to do anything about this. C1 or C2 would have the same problem if you disabled the intrinsic. Generally the rule is that if the interpreter has an intrinsic the compilers must as well. I would lean towards closing this as will not fix.
09-06-2017
ILW = Infinite recompilation of method, only with Graal which is used for experimental AOT in JDK 9, disable Graal/AOT = MLM = P4
09-06-2017
Funny. Maybe we should check if the interpreter and C1 intrinsics are still necessary.
16-12-2015
This appears to be a deopt pathology caused by the fact that C1 and the interpreter have a pow intrinsic but Graal does not when it's been removed. This means that the code in Math.pow never gets executed in the interpreter so the invokestatic for StrictMath.pow never gets resolved. This causes the compilation to consist only of a deopt unresolved. Since the deopts are imprecise we can never actually execute the invokestatic to get the bytecode resolved.
15-12-2015