fdlibm behaviour on non-HotSpot platforms

[Joe Darcy]

Greetings.

gnu_andrew at 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,