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
