Hi Joe,
On Jan 16, 2014, at 2:54 PM, Joseph Darcy wrote:
>> Please see the updated
>> webrevhttp://cr.openjdk.java.net/~bpb/6667086/webrev.2/.
>
> New webrev looks good.
The change has been pushed.
Note that I filed this linked issue to capture the
Math.next{After,Up}({float,double}) changes
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/66
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
On 01/15/2014 01:28 PM, Brian Burkhalter wrote:
Issue: https://bugs.openjdk.java.net/browse/JDK-6667086
Webrev: http://cr.openjdk.java.net/~bpb/6667086/webrev/
According to micro-benckmarks, there is no statistically significant
performance change due to applying this patch but the code defini
6:43:47 AM GMT -08:00 US/Canada Pacific
Subject: Re: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value)
contains inefficient test for NaN
On Jan 15, 2014, at 10:28 PM, Brian Burkhalter
wrote:
> Issue:https://bugs.openjdk.java.net/browse/JDK-6667086
> Webrev:
On Jan 15, 2014, at 10:28 PM, Brian Burkhalter
wrote:
> Issue:https://bugs.openjdk.java.net/browse/JDK-6667086
> Webrev: http://cr.openjdk.java.net/~bpb/6667086/webrev/
>
> According to micro-benckmarks, there is no statistically significant
> performance change due to applying
Issue: https://bugs.openjdk.java.net/browse/JDK-6667086
Webrev: http://cr.openjdk.java.net/~bpb/6667086/webrev/
According to micro-benckmarks, there is no statistically significant
performance change due to applying this patch but the code definitely looks
cleaner.
Thanks,
Brian
