FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-b105, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux hssa1.aoa.twosigma.com 2.6.18-ts1 #1 SMP PREEMPT Fri Sep 29 14:06:04 GMT 2006 x86_64 x86_64 x86_64 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
successive invocations of Math.log() produce inconsistent results (possibly depending on compilation because -Xint or -XX:CompleThreshold=0 always produces consistent results). The number of iterations in the actual result varies.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
$ javac LogTest.java
$ java -cp . LogTest

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
n=17197.0
SUCCESS!
ACTUAL -
n=17197.0
ERROR after 43235 iterations:
previous value: 9.7524902289842 (40238146663817e8)
 current value: 9.752490228984199 (40238146663817e7)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class LogTest {

    public static void main(String[] args)
    {
        double n = Integer.parseInt("17197");
        System.out.println("n=" + n);
        double d = Math.log(n);
        for (int i = 0; i < 100000; i++) {
            double e = Math.log(n);
            if (e != d) {
                System.err.println("ERROR after " + i + " iterations:\n" +
                   "previous value: " + d + " (" +
                   Long.toHexString(Double.doubleToLongBits(d)) + ")\n" +
                   " current value: " + e + " (" +
                   Long.toHexString(Double.doubleToLongBits(e)) + ")");
                System.exit(1);
            }
        }
        System.err.println("SUCCESS!");
        System.exit(0);
    }
}

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

CUSTOMER SUBMITTED WORKAROUND :
run with -Xint -XXCompilerThreshold=0 produces the expected result, on the other hand, is that a complete fix? Are floating point results reliable?
Posted Date : 2007-03-27 19:39:44.0

N/A

Should be investigated.
Posted Date : 2007-04-03 23:26:06.0

The interpreter is using the C implementation and compiled code is using the log instructions on x86 but the interpreter and compiler are required to use the same implementation so that Math.log is self consistent.  The amd64 interpreter has the code to use the x86 instruction but some code in AbstractInterpreterGenerator::generate_method_entry keep it from getting used.
Posted Date : 2009-03-26 18:00:09.0

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/819880572f09
Posted Date : 2009-04-06 23:28:12.0

-XX:CompilerThreshold=0 does not work reliably. Unfortunately due to the hard-coded way optimization of Math.log() is done, using -XX:CompileCommand=exclude,java/lang/Math,log -XX:CompileCommand=exclude,java/lang/StrictMath,log does not work either. One needs to avoid compiling each enclosing function that invokes Math.log(). Since the Math.log() signature is hard-coded in the optimizer, even replacing Math.class will not work. In the future please consider using a keyword or an annotation to the optimizer so that a user can override such optimizations.

The same problem seems to exist for Math.sin() and Math.cos().

Here is an example for sin. cos is similarly broken...

public class SinTest {

    public static void main(String[] args)
    {
        double n = Double.parseDouble("0.4575");
        double d = Math.sin(n);
        System.out.println("n=" + n + ",sin(n)=" + d);
        for (int i = 0; i < 100000; i++) {
            double e = Math.sin(n);
            if (e != d) {
                System.err.println("ERROR after " + i + " iterations:\n" +
                   "previous value: " + d + " (" +
                   Long.toHexString(Double.doubleToLongBits(d)) + ")\n" +
                   " current value: " + e + " (" +
                   Long.toHexString(Double.doubleToLongBits(e)) + ")");
                System.exit(1);
            }
        }
        System.err.println("SUCCESS!");
        System.exit(0);
    }
}

This is an extremely annoying bug, not allowing to match two different runs.
See my report at 

https://bugzilla.redhat.com/show_bug.cgi?id=500077

Also see a patch at 
http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/819880572f09

The problem also exists in 
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b59)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b03, mixed mode)

see the code t1.java from 
https://bugzilla.redhat.com/show_bug.cgi?id=500077

$java -server -Xmx6500000K t1
 LOG(84572)=11.345358521544759
 LOG(84572)=11.34535852154476
Exception in thread "main" java.lang.RuntimeException: Value mismatch: 11.34535852154476 and 11.345358521544759 arg=84572 try=21
	at t1.main(t1.java:81)

The difference between 
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)

and 

java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b59)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b03, mixed mode)

is that 1.6.0_14 need just few seconds to fail
$ java -server -Xmx6500000K t1
 LOG(84572)=11.34535852154476
 LOG(84572)=11.345358521544759
Exception in thread "main" java.lang.RuntimeException: Value mismatch: 11.345358521544759 and 11.34535852154476 arg=84572 try=0
	at t1.main(t1.java:81)

while 1.7.0-ea needs about 5-10 minutes to fail, memory usage 
should reach about 2.5Gb, then it fails
java -server -Xmx6500000K t1
 LOG(84572)=11.345358521544759
 LOG(84572)=11.34535852154476
Exception in thread "main" java.lang.RuntimeException: Value mismatch: 11.34535852154476 and 11.345358521544759 arg=84572 try=21
	at t1.main(t1.java:81)

Why is listed as fixed and closed when the bug is still there?

>> Why is listed as fixed and closed when the bug is still there?

This bug is marked fixed in hs16 which will ship with JDK 6 Update 18
due out later this year.  It will also be available in the latest JDK7 promotions.

>> This bug is marked fixed in hs16 which will ship with JDK 6 Update 18
>> due out later this year.

Excellent.  How does one make that connection between "hs16" and Update 18?

Do you know if this will also fix the other transcendental math issues?