On 24 May 2010 13:55, Xerxes Rånby <xer...@zafena.se> wrote:
> Hi
>
> Im hoping to find someone who can enlighten me how to resolve a bug
> where some hotspot JITs
> fails the hotspot/test/compiler/6539464 jtreg regression test.
>
> The testcase looks like:
>
> public class Test {
> static double log_value = 17197;
> static double log_result = Math.log(log_value);
>
> public static void main(String[] args) throws Exception {
> for (int i = 0; i < 1000000; i++) {
> double log_result2 = Math.log(log_value);
> if (log_result2 != log_result) {
> throw new InternalError("Math.log produces inconsistent
> results: " + log_result2 + " != " + log_result);
> }
> }
> }
> }
>
> When running this testcase using various jvms / architectures i get varying
> results of the calculated log_result2 and log_result which
>
> ARCH+JVM combination log_result
> (javac) log_result2 (jit) passes regression test?
> ia32+OpenJDK Server VM (build 14.0-b16, mixed mode)
> 9.752490228984199 9.752490228984199 yes
> arm+OpenJDK Shark VM (build 16.0-b13, mixed mode) 9.75249022898412
> 9.752490228984199 no
> x86_64+OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) 9.75249022898412
> 9.752490228984199 no
>
> While trying to figure out whats the correct result for the log(17197)
> calculation i tested what StrictMath.log outputs:
> StrictMath.log(17197) = 9.75249022898412
>
> And in order to get an independent mathematically correct opinion of what
> log(17197) equals i asked wolfram alpha:
> http://www.wolframalpha.com/input/?i=log%2817197%29
> log(17197) = 9.7524902289841994797298917760120602447583441794533189705223...
> or in short 9.752490228984199
>
> So we have a situation where javac, jit, Math and StrictMath generates
> inconsistent results.
> How do we resolve this situation?
>
> Quoting the Math package java doc:
> "If a method always has an error less than 0.5 ulps, the method always
> returns the floating-point number nearest the exact result; such a
> method is correctly rounded. A correctly rounded method is
> generally the best a floating-point approximation can be; however,
> it is impractical for many floating-point methods to be correctly
> rounded. Instead, for the Math class, a larger error
> bound of 1 or 2 ulps is allowed for certain methods"
>
> Would this quotation imply that both log(17197) calculation results above are
> correct ( 9.752490228984199 and 9.75249022898412 )?
> If both calculations are correct then I propose that we should change the
> hotspot/test/compiler/6539464 jtreg regression test to make all
> JVM's pass the test when they are within +- 1 ulps from the mathematically
> correct answer of:
> 9.7524902289841994797298917760120602447583441794533189705223...
>
> Cheers and have a great day!
> Xerxes
>
>
Do x86 and x86_64 give the same results if you actually use the same
version of HotSpot as you do on ARM?
--
Andrew :-)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
