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

Joseph Darcy joe.darcy at oracle.com
Thu Jan 16 22:54:48 UTC 2014

Hi Brian,

On 1/16/2014 10:51 AM, Brian Burkhalter wrote:
> 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/.

New webrev looks good.

>> 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?

I don't think so. The canonical isNaN idiom is just (x != x) so normal 
inlining should cover it, assuming the processor has decent NaN support.


More information about the core-libs-dev mailing list