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
