Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8063086

Math.pow yields different results upon repeated calls

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 7u80, 8u25, 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Introduced In Build:
      b03
    • Introduced In Version:
    • Resolved In Build:
      b48
    • CPU:
      x86_64
    • OS:
      linux

      Backports

        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 ----------

          Issue Links

            Activity

            Hide
            dholmes David Holmes added a comment -
            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.
            Show
            dholmes David Holmes added a comment - 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.
            Hide
            neliasso Nils Eliasson added a comment -
            ILW=Possible bad float precision, easy to reproduce, none=MMH=P3
            Show
            neliasso Nils Eliasson added a comment - ILW=Possible bad float precision, easy to reproduce, none=MMH=P3
            Hide
            roland Roland Westrelin added a comment -
            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.
            Show
            roland Roland Westrelin added a comment - 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.
            Hide
            twisti Christian Thalinger added a comment -
            Is this actually a bug or within the specification?
            Show
            twisti Christian Thalinger added a comment - Is this actually a bug or within the specification?
            Hide
            darcy Joe Darcy added a comment -
            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.
            Show
            darcy Joe Darcy added a comment - 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.
            Hide
            twisti Christian Thalinger added a comment -
            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.
            Show
            twisti Christian Thalinger added a comment - 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.
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6de45a355478
            User: roland
            Date: 2015-01-12 17:51:47 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6de45a355478 User: roland Date: 2015-01-12 17:51:47 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6de45a355478
            User: lana
            Date: 2015-01-28 23:16:26 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6de45a355478 User: lana Date: 2015-01-28 23:16:26 +0000

              People

              • Assignee:
                roland Roland Westrelin
                Reporter:
                webbuggrp Webbug Group
              • Votes:
                0 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: