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
