RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]

Jie Fu jiefu at openjdk.java.net
Wed Apr 21 09:17:28 UTC 2021

On Wed, 21 Apr 2021 08:44:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > This may be unsafe. AFAIK there is no guarantee about the monotonicity of `Math.pow(x, y)` as y moves from `Math.pow(x, nextAfter​(0.5, -1)` to `Math.pow(x, 0.5)` to `Math.pow(x, nextAfter​(0.5, 1)` for all x. Did anyone look?
> > 
> > 
> > Thanks @theRealAph for your review.
> > What did you mean by `Math.pow(x, nextAfter​(0.5, -1)` and `Math.pow(x, nextAfter​(0.5, 1)` ?
> From the spec, "errors are required to be semi-monotonic: whenever the mathematical function is non-decreasing, so is the floating-point approximation, likewise, whenever the mathematical function is non-increasing, so is the floating-point approximation."
> nextAfter "Returns the floating-point number adjacent to the first argument in the direction of the second argument."
> Using sqrt() rather than pow() for pow(x,0.5) will return different results for some arguments. For this optimization you're proposing to be safe, you need to prove that in such cases the "Results must be semi-monotonic" requirement is still satisfied.
> There may exist values of pow(x,0.5) where, if we substitute sqrt() this requirement is not met. I don't immediately know how to prove this does not happen. I think that to do so would require careful analysis.

Hi @theRealAph ,

Thanks for your clarification.

Actually, this optimization has been long used for Java.
And we don't see any problems of it, right?
So I don't think it will cause problems in the future.

What do you think of the same optimization in the HotSpot which has been applied more than 10 years ago?

And also the same optimization in the Java lib?



PR: https://git.openjdk.java.net/jdk/pull/3404

More information about the hotspot-compiler-dev mailing list