RFR (S): 7177917: Failed test java/lang/Math/PowTests.java

[Vladimir Kozlov]

Did you run refworkload? Additional checks will increase code size and may 
slowdown performance. Did you consider the fix which keeps unctrap but instead 
of going into java code generate call to runtime only if there were NaN cases.

May be call_runtime_pow_exp() instead of pow_exp_call_runtime() name.

Fix comment "then go to Strict Math" since it is not true anymore.

result_region and result_val are used only when !if_slow->is_top().

In inline_pow() next comment is strange ("but and"):
  // max_jlong is odd but and 9.223372036854776E18 is even

Not for this fix but for future, may be we should use exponent values checks (as 
in __ieee754_pow() method) instead of converting D2L and L2D which could be 
expensive.

Thanks,
Vladimir

Roland Westrelin wrote:
> The current intrinsics for pow and exp in c2 do not handle all cases and may trigger uncommon traps. When that happens, the next compilations won't attempt to use the intrinsic code and rather will fallback to inlining the java implementations of pow or exp which call the StrictMath implementation. So a java application could get different results for the same computation (either the intrinsic version or the StrictMath version). This is solved by never triggering uncommon traps in the intrinsic pow/exp but rather call the runtime on corner cases (similar to the interpreter/c1 code).
> A similar problem could show up if ConditionalMoveLimit=0: c2 wouldn't use the same implementation as the interpreter/c1. So we can't offer to bail out if ConditionalMoveLimit is 0.
> In inline_pow, the else branch of:
> if( jvms()->depth() >= 1 ) {
> was never tested (because we forbid compilation of pow as a standalone method) and had several problems that this change fixes.
> 
> An alternate fix would have been to simply forbid the inlining of the java implementation of pow/exp when intrinsification fails.
> 
> http://cr.openjdk.java.net/~roland/7177917/webrev.00/
> 
> Roland.