Bug ID: JDK-6214949 JCK1.5a: api/java_util/Random/index.html#Random test fails, mustang

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 6
6 b61Fixed

JCK            : jck1.5a
J2SE           : FAIL -> mustang b16
                 PASS -> mustang b15
Platform[s]    : FAIL -> turbo 8 + , win2k
switch/Mode    : FAIL -> -client -Xcomp 
                 PASS -> default, -client, -server
                 
JCK test owner : http://javaweb.sfbay/jcce/tcks/jck/docs/others/owners.jto

Failing Tests   : 
api/java_util/Random/index.html

Test source location:
=====================
/net/jtgb4u4c/export/sail1/testarea/jck1.5a.b01/JCK-runtime-15a/tests/api/java_util/Random/RandomTests.java

jtr file location:
==================
attached

How to reproduce:
====================
-------script START---------------------
#!/bin/sh

JDK="/export/jdk/b16/linux-i586/jdk1.6.0"
JCK="/net/jtgb4u4c.sfbay/export/sail1/testarea/jck1.5a.b01/JCK-runtime-15a"
CLASSPATH="$JCK/classes:$JCK/lib/javatest.jar"

TEST="javasoft.sqe.tests.api.java.util.Random.RandomTests -TestCaseID ALL"

echo `cat $JCK/build.txt | grep JCK_VERSION` `cat $JCK/build.txt | grep JCK_BUILD`

$JDK/bin/java -client -Xcomp -showversion -cp $CLASSPATH $TEST

--------script END----------------------

Test output:
=============
JCK_VERSION=1.5a JCK_BUILD_ID=b01
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b16)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b16, compiled mode, sharing)

Random2001: Passed. OKAY
Random2002: Passed. OKAY
Random2003: Passed. OKAY
Random2004: Passed. OKAY
Random0001: Passed. OKAY
Random2005: Passed. OKAY
Random2006: Passed. OKAY
Random2007: Passed. OKAY
Random2008: Passed. OKAY
Random2009: Passed. OKAY
Random2010: Passed. OKAY
Random2011: Passed. OKAY
Random2012: Passed. OKAY
Random2013: Failed. Incorrect result
nextGaussian(): -0.39016704137993774
expected: -0.39016704137993785
STATUS:Failed.test cases: 14; passed: 13; failed: 1; first test case
failure: Random2013

Specific Machine Info:
=====================
[root@lunar root]# uname -a
Linux lunar 2.4.18-1smp #1 SMP Mon Apr 29 02:19:46 JST 2002 i686 unknown


###@###.### 2005-2-02 02:25:07 GMT

SUGGESTED FIX http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2005/20051107073357.azeem.6214949/workspace/webrevs/webrev-2005.11.07/index.html

10-11-2005

EVALUATION C1 was returning incorrect values for Math.log. Xcomp produced a compiled version of Math.log without the intrinsifcation that the interpreter is able to call that ends up calling StrictMath.log which returns a different answer. Without Xcomp it won't fail because we'll never compile Math.log, only inline it so the VM will always use the intrinsified version. The fix is to modify the parser to compile and inline the intrinsics. Also compile_library_method and supporting functions have been deleted since they are no longer needed.

13-10-2005

EVALUATION As this test starting failing in build16 and the failing test involves Math.log, the underlying cause is most likely 6196383 "LN and LOG10 should be implemented for C1" which was fixed in build 20; the failure persists in build 20 after 6213988 "Change in behavior of Math.log() with intrinsified version" has been fixed. I have reproduced the difference in behavior in a stand-alone test program run on an x86 linux box. The difference in vm behavior in this instance should be investiated further. However, a related issue is faulty specification and implementation of Random.nextGaussian. The specification for that method quotes the source used to implement it. That source uses Math.log. However, as of 1.3, Math.log is not required to compute the same value on all platforms; for that level of reproducability, the StrictMath.log method should be used. I will file a separate bug to track the StrictMath vs Math specification issue. ###@###.### 2005-1-25 04:05:46 GMT

25-01-2005

Relates :	JDK-6221118 - java.util.Random.nextGaussian should specify StrictMath instead of Math methods
Relates :	JDK-6196383 - LN and LOG10 should be implemented for C1
Relates :	JDK-6213988 - Change in behavior of Math.log() with intrinsified version