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.dui...@oracle.com> wrote: > Looks fine to me! > > Mike > > On Sep 22 2014, at 15:34 , Brian Burkhalter <brian.burkhal...@oracle.com> > wrote: > >> Hi Aleksey, >> >> On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev <aleksey.shipi...@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 >
