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

          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: