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

[Joseph Darcy]

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.

-Joe