JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN

[Brian Burkhalter]

Hi Joe,

On Jan 16, 2014, at 9:23 AM, Joe Darcy wrote:

> A few comments here. If you are making this change in Double, you would make the corresponding change in Float too.

Please see the updated webrev http://cr.openjdk.java.net/~bpb/6667086/webrev.2/.

> Some explanation on why I wrote these methods with the integer-field-based null check, some processors are implemented such that operating on the IEEE non-finite value of NaN and +/- infinity runs much more slowly than operating on normal value, sometimes orders of magnitude more slowly.
> 
> For the bitwise conversion methods, since we were biting the bullet to do the conversion anyway, I thought I would avoid the worst-case cost of tripping over a NaN by doing the NaN check on the integer value.

Thanks for the explanation. Would {Double,Float}.isNaN() perhaps be good candidates for VM intrinsics?

> However, I will vote to approve the replacement of that code with "isNaN" checks as long as Float and Double are both converted.

This has been done in the patch linked above.

Thanks,

Brian