JDK 9 RFR of JDK-8134795: Port fdlibm pow to Java

[Joseph D. Darcy]

Hello,

At long last, I've started the port of the C version of FDLIBM (freely 
distributable math library) from C to Java, beginning with the pow method:

     JDK-8134795: Port fdlibm pow to Java
     http://cr.openjdk.java.net/~darcy/8134795.6/

The FDLIBM algorithms provide direct backing to the more interesting 
methods in java.lang.StrictMath and indirect backing to the 
corresponding java.lang.Math methods on some platforms (depending on 
whether or not platform-optimized alternative versions are being used).

Having this functionality in Java versus C offers a number of 
advantages, including easier maintenance and improved performance (the 
Java -> C -> Java transitions are expensive).

My general approach for code organization of the port is to add a new 
package-private class named "FdLibm" in the java.lang package. The 
calculation code to support a particular math function will have its own 
nested class inside FdLibm. This structure allows sharing of helper code 
across the different FDLIBM functions without bloating the number of 
source files in java.lang. Floating-point constants will generally be 
initialized using the precise (if obscure) hexadecimal floating-point 
notation accepted in Java since JDK 5. (See JLS 3.10.2 Floating-Point 
Literals for details, 
https://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10.2) 
For further clarify, underscores are used to separate groups of digits 
to make it easier to see if a full-precision value is being provided 
(underscores in numeric literals were Project Coin feature in JDK 7).

Future refinements of the port may restrict the range of the strictfp 
modifier or remove it entirely. The current usage of strictfp should be 
correct, if not necessarily optimal from a performance perspective. To 
make floating-point code reproducible about platforms, a semantic 
requirement for StrictMath, within the FP-default and FP-strict model  
in Java, it is not necessarily required to declare a method strictfp. 
Declaring a method strictfp will do the job, but if the code in question 
neither overflows nor underflows, strictfp is not necessary for 
cross-platform reproducibility. If the code only overflows and 
underflows are *not* possible, storing down to a variable can in some 
cases be sufficient for reproducibility without strictfp. Additional 
case analysis along this lines would need to be done to the pow 
algorithm to limit the scope of its strictfp usage.)

The original C code was written many years back and was written in a 
style different than idiomatic Java today. The port as it stand is much 
closer to idiomatic Java than the original; however, some vestiges of 
original style remain, a few to make mapping back to the C code easier 
if that is necessary. To make the reviewing easier, in the webrev I 
listed e_pow.c as the original file to compare FdLibm.java against. 
However, in actuality e_pow.c is deleted and FdLibm.java is added as a 
new file. The original C code was severely whitespace deficient compared 
to idiomatic Java so many of the line-by-line differences are just to 
provide more humane and readable spacing.

A substantively similar version of this port has gone through jprt and 
the build succeed and jdk_lang test group passed on all platforms.

Thanks to Brian Burkhalter for earlier pre-reviews on several of the 
previous iterations of this port. Earlier iterations of the port were 
also reviewed by an Oracle numerical expert outside of the JDK group.

Thanks,

-Joe