JDK-8063086 : Math.pow yields different results upon repeated calls
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7u80,8u25,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2014-11-05
  • Updated: 2017-10-11
  • Resolved: 2015-01-12
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 7 JDK 8 JDK 9
7u121Fixed 8u102Fixed 9 b48Fixed
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)


FULL OS VERSION :
Linux host 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
The function Math.pow() returns slightly different results upon repeated calls with exactly the same input parameters. It seems as if the implementation (floating point precision) is switched internally at some point during execution.

A mathematical function must return consistent and reproducible results within one VM instance.

also see http://stackoverflow.com/questions/26746623/math-pow-yields-different-results-upon-repeated-calls



THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: No

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

REGRESSION.  Last worked in version 8u11

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the example code given below.

EXPECTED VERSUS ACTUAL BEHAVIOR :
It should print nothing, but it prints:
Math.pow()
i=15573
x=2.862738293257239E7
p=2.8627382932572395E7

REPRODUCIBILITY :
This bug can be reproduced often.

---------- BEGIN SOURCE ----------
import java.util.function.BiFunction;

public class PowerTest {

    private static final int N = 1000000;
    private static final double base = 5350.456329377186;
    private static final double exp = 2.0;

    private static double eval(final BiFunction<Double, Double, Double> f) {
        return f.apply(base, exp);
    }

    private void loop(final String s, final BiFunction<Double, Double, Double> f) {
        double x = eval(f);
        for (int i = 0; i < N; i++) {
            final double p = eval(f);
            if (x != p) {
                System.out.println(s + "\ni=" + i + "\nx=" + x + "\np=" + p);
            }
            x = p;
        }
    }

    public void mathPow() {
        loop("Math.pow()", Math::pow);
    }

    public void strictMathPow() {
        loop("StrictMath.pow()", StrictMath::pow);
    }

    public static void main(final String[] args) {
        final PowerTest pt = new PowerTest();
        pt.mathPow();
        pt.strictMathPow();
    }
}

---------- END SOURCE ----------


Comments
Thanks for clarifying. I agree that it is nice to get the same answer on all different levels of optimization. The reason I brought this up is we need to find another way to deal with optimizations like this because it clearly doesn't scale to add these special cases in the assembler.
06-01-2015

The specification does not explicitly state "on the same VM (for however that would be defined), for the same values x and y, pow(x, y) must return the same value each time it is called." However, it is clearly ugly misbehavior of the system when this kind of inconsistency occurs external from any sort of reasonable user control. Whenever a numerical intrinsification is added, it should be added to the interpreter, C1, C2, (C3, C4, etc.) so that the numerical behavior is humane. For the trigonometric functions, they started out as inconsistent across the interpreter and and the compilers, but were quickly made consistent to avoid just the sort of problem being reported here for pow.
06-01-2015

Is this actually a bug or within the specification?
06-01-2015

Following JDK-8029302, C2 treats x^2 as a special case and computes x * x while the interpreter doesn't have special case for X^2.
19-12-2014

ILW=Possible bad float precision, easy to reproduce, none=MMH=P3
11-11-2014

Re-directing to compiler team. Issue only seems to occur with server VM. client is okay as is interpreter. So I would guess that C2 intrinsics have different behaviour to interpreter and C1 routines. Even so this could all be within spec anyway.
06-11-2014