On 2010-05-24 15:44, Andrew John Hughes wrote:
> 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?
>
Im only able to test x86:
But no javac still produces different ressult when compiling
static double log_result = Math.log(log_value);
and running javac on x86 and arm using the same version of hotspot:
ARCH+JVM combination log_result (javac)
log_result2 (jit) passes regression test?
ia32+OpenJDK Shark VM (build 16.0-b13, mixed mode) 9.752490228984199
9.752490228984199 yes
arm+OpenJDK Shark VM (build 16.0-b13, mixed mode) 9.75249022898412
9.752490228984199 no
