JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math"

[Joe Darcy]

Hi Jeff.

I'll consider that for some possible future work.

Thanks,

-Joe

Jeff Hain wrote:
> Hi.
> There are some possible optimizations for some methods.
>
> For nextAfter(double,double) (same for float version), instead of 
> testing NaN-ity right away,
> we can test most common (or at least regular) cases first:
> public static double nextAfter(double start, double direction) {
>     // Balancing out by branching to going-down case first,
>     // for it is heavier than going-up case (test if start is +-0.0).
>     if (start > direction) {
>         // Going down.
>         if (start == 0.0d) {
>             // start is +0.0 or -0.0
>             return -Double.MIN_VALUE;
>         }
>         final long transducer = Double.doubleToRawLongBits(start);
>         assert transducer != 0L;
>         return Double.longBitsToDouble(transducer + ((transducer > 0L) 
> ? -1L:1L));
>     } else if (start < direction) {
>         // Going up.
>         // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0)
>         // then bitwise convert start to integer.
>         final long transducer = Double.doubleToRawLongBits(start + 0.0d);
>         return Double.longBitsToDouble(transducer + ((transducer >= 
> 0L) ? 1L:-1L));
>     } else if (start == direction) {
>         return direction;
>     } else { // start and/or direction is NaN
>         return start + direction;
>     }
> }
>
> Same for nextUp(double) and float version (also, testing transducer >= 0L
> instead of d >= 0.0D seems to help):
> public static double nextUp(double d) {
>     if (d < Double.POSITIVE_INFINITY) {
>         final long transducer = Double.doubleToRawLongBits(d + 0.0D);
>         return Double.longBitsToDouble(transducer + ((transducer >= 
> 0L) ? 1L:-1L));
>     } else { // d is NaN or +Infinity
>         return d;
>     }
> }
>
> -Jeff
>
> ------------------------------------------------------------------------
> *De :* "joe.darcy at oracle.com" <joe.darcy at oracle.com>
> *À :* core-libs-dev <core-libs-dev at openjdk.java.net>
> *Envoyé le :* Samedi 17 Septembre 2011 3h52
> *Objet :* JDK 8 code review request for 7091682 "Move sun.misc.FpUtils 
> code into java.lang.Math"
>
> Hello.
>
> Please review the changes to address
>
>   7091682 "Move sun.misc.FpUtils code into java.lang.Math"
>   http://cr.openjdk.java.net/~darcy/7091682.0/ 
> <http://cr.openjdk.java.net/%7Edarcy/7091682.0/>
>
> As implied by the synopsis, where appropriate JDK-implementation code 
> used to provide functionality in java.lang.Math and 
> java.lang.StrictMath is moved out of sun.misc.* and into 
> java.lang.Math.  Uses of methods available in java.lang.Math and 
> switched to that entry point as opposed to the sun.misc one.  
> Additionally, the sun.misc methods whose implementation was moved were 
> also deprecated.
>
> Later in JDK 8, I will probably add some of the remaining 
> un-deprecated methods in sun.misc.FpUtils as java.lang.Math/StrictMath 
> methods.
>
> Thanks,
>
> -Joe
>
>