fdlibm behaviour on non-HotSpot platforms
Hi, Christian Thalinger (twisti) of the CACAO project has recently been looking at using the OpenJDK libraries with CACAO as the VM (via a suitable libjvm.so) to allow it to be built on non-HotSpot supported platforms (e.g. ppc, ppc64, alpha). I've just been testing this on ppc64 this morning. The trigonometric functions (sin, cos, tan) seem to run into difficulties on these new platforms. On x86, x86_64 and sparc, sin(0.7) returns the correct answer of 0.644217687237691. On alpha, the same test gives -0.9589410493575494 while it returns the input value of 0.7 on both ppc and ppc64. Ironically, gij on ppc64 gives the correct answer. This was spotted when running SPECs check: 5$ cacao -cp ./check.jar spec/jbb/validity/PepTest LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=HUP LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=INT LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=TERM LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetSystemPackage: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetSystemPackage: IMPLEMENT ME! testIf: OK testArray: OK testBitOps: OK testFor: OK testDiv: OK testTableSwitch: OK testLookupSwitch: OK testHiddenField: OK checkRemainders: long double OK checkMathFcts: sin(0.7) evaluated to: 0.7, expected: 0.644218 cos(0.7) evaluated to: 1.0, expected: 0.764842 acos(0.7) evaluated to: 1.5707963267948966, expected: 0.795399 atan(0.7) evaluated to: 0.7, expected: 0.610726 ****************************************** Some math function failed ****************************************** Primes less than 50: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 testExc1(simple throw/catch): OK testExc2(skip catch clauses): OK testExc3(catch in inner): OK testExc4(catch in outer): OK testExc5(rethrow): OK testExc6(throw accross call): OK testExc7(throw accr. 2 calls): OK loopExitContinueInExceptionHandler: OK testStringHash: OK testClone: OK testObjectArray: OK checkInstanceOf: OK checkInterfaceInstanceOf: OK testWaitNull: OK testVarAndMethodNameClash: OK testMisk: OK testGC: OK testRandom : OK PepTest: error Any idea what the problem may be and when this may be rectified? Thanks, -- Andrew :)
Greetings. gnu_andrew@member.fsf.org wrote:
Hi,
Christian Thalinger (twisti) of the CACAO project has recently been looking at using the OpenJDK libraries with CACAO as the VM (via a suitable libjvm.so) to allow it to be built on non-HotSpot supported platforms (e.g. ppc, ppc64, alpha). I've just been testing this on ppc64 this morning.
The trigonometric functions (sin, cos, tan) seem to run into difficulties on these new platforms. On x86, x86_64 and sparc, sin(0.7) returns the correct answer of 0.644217687237691. On alpha, the same test gives -0.9589410493575494 while it returns the input value of 0.7 on both ppc and ppc64. Ironically, gij on ppc64 gives the correct answer.
To give some background, in HotSpot the Math.{sin, cos, tan} methods are often intrinsified, that is, they have JVM-internal implementation (which meet the spec) rather than using the method compiled from the source of java.lang.Math. The StrictMath class is specified to use the fdlibm algorithms and currently it usually calls down to the C versions of those functions compiled as part of the JDK. The C code in fdlibm require a memory overlay between the bits of a 64-bit integer and a double. The source techniques used for this often break when the C compiler optimization level is too high. We've had to tweak the C compiler settings for fdlibm over the years on different platforms and often compile fdlibm with different options than other native code in the JDK so I would suspect some sort of build problem. The Java language and vm require support for the full set of IEEE 754 floating-point values, including NaN and infinity. At least older Alpha chops did not have full hardware support for these values and compiler options were needed to enable their use. More recent Alphas do have more complete hardware support but compiler options may be needed. (Also note that the Alpha hardware uses a weaker memory model than required by Java so some work would be needed in a vm to insert fences, etc. as appropriate.) -Joe Darcy
This was spotted when running SPECs check:
5$ cacao -cp ./check.jar spec/jbb/validity/PepTest LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=HUP LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=INT LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=TERM LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetSystemPackage: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetSystemPackage: IMPLEMENT ME! testIf: OK testArray: OK testBitOps: OK testFor: OK testDiv: OK testTableSwitch: OK testLookupSwitch: OK testHiddenField: OK checkRemainders: long double OK checkMathFcts: sin(0.7) evaluated to: 0.7, expected: 0.644218 cos(0.7) evaluated to: 1.0, expected: 0.764842 acos(0.7) evaluated to: 1.5707963267948966, expected: 0.795399 atan(0.7) evaluated to: 0.7, expected: 0.610726
****************************************** Some math function failed ****************************************** Primes less than 50: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 testExc1(simple throw/catch): OK testExc2(skip catch clauses): OK testExc3(catch in inner): OK testExc4(catch in outer): OK testExc5(rethrow): OK testExc6(throw accross call): OK testExc7(throw accr. 2 calls): OK loopExitContinueInExceptionHandler: OK testStringHash: OK testClone: OK testObjectArray: OK checkInstanceOf: OK checkInterfaceInstanceOf: OK testWaitNull: OK testVarAndMethodNameClash: OK testMisk: OK testGC: OK testRandom : OK PepTest: error
Any idea what the problem may be and when this may be rectified?
Thanks,
On Fri, 2007-08-03 at 10:16 -0700, Joe Darcy wrote:
The Java language and vm require support for the full set of IEEE 754 floating-point values, including NaN and infinity. At least older Alpha chops did not have full hardware support for these values and compiler options were needed to enable their use. More recent Alphas do have more complete hardware support but compiler options may be needed. (Also note that the Alpha hardware uses a weaker memory model than required by Java so some work would be needed in a vm to insert fences, etc. as appropriate.)
Hi! I don't know what I did, maybe some things I had to add to the build systems, who knows, but it seems to work now. I can tell for sure it works on PowerPC and PowerPC64. I still have problems to get the whole thing built on Alpha, which is also a floating point problem, but that's another story... - twisti
participants (3)
-
Christian Thalinger
-
gnu_andrew@member.fsf.org
-
Joe Darcy