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

[Volker Simonis]

Hi Joe,

nice clean-up! From a maintenance point of view the the old fdlibm has
been a burden and a constant source of warnings with newer compilers.

What about the final arrays in Pow.compute (BP, DP_H, DP_L). In the
Interpreter (and even in C2 without EscapeAnalysis) this will lead to
allocations every time the method is called. Making them static fields
of 'Pow' will help here. On the other hand, if the arrays are static
fields of 'Pow', C2 will not be able to directly use the constants but
will have to load them from the array. So altogether, your current
implementation is optimal with HotSpot (with EscapeAnalysis turned on
by default) but might not be the best for other VMs without
EscapaAnalysis.

Have you done any benchmarking which compares the new Java against the
old C implementation?

Regards,
Volker

On Wed, Sep 16, 2015 at 4:11 AM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> 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