JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

[Brian Burkhalter]

Hi  Mike,

Thanks for the review.

For the sake of completeness I tested converting 89.0 * Double.MIN_VALUE to radians and Double.MAX_VALUE / 89.0 to degrees. The old version gives 0.0 and Double.POSITIVE_INFINITY, respectively, whereas the webrev.01 version gives the respective results 1.0E-323 and 1.1573059492949775E308.

Brian

On Sep 22, 2014, at 4:24 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> Looks fine to me!
> 
> Mike
> 
> On Sep 22 2014, at 15:34 , Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
>> Hi Aleksey,
>> 
>> On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
>> 
>>> Hm, and this compiler transformation works in strictfp context? I hope
>>> compilers do the constant folding in strictfp/fdlibm mode…
>> 
>> Yes.
>> 
>>> I would probably just go and declare the private compile-time constants.
>>> This is safer, since: a) you are not at the mercy of optimizing compiler
>>> anymore (have you tried the benchmark with C1?); b) the initializing
>>> expressions are FP-strict, less opportunity for hard to diagnose numeric
>>> problem.
>> 
>> I created an alternate webrev using compile-time constants per your suggestion:
>> 
>> http://cr.openjdk.java.net/~bpb/4477961/webrev.01/
>> 
>> The performance improvement is similar to that cited for webrev.00.
>> 
>> If this version is preferable it will need approval from a JDK 9 Reviewer, of course.
>> 
>> Thanks,
>> 
>> Brian
>