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

[Vladimir Kozlov]

It looks good.

Thank you for looking on refworkload. I would suggest to write a microbenchmark, we will need it anyway for SSE 
implementation. Two separate subtests for pow() and exp() called in small loop over pre-generated (in array) "random" 
(started from the same seed) normal (not NaN) values. Measure it's performance after warmup phase. Then run the same 
methods over different values (to cove at least some cases in our code) which will produce NaNs to force recompile (or 
not as in your first implementation). Measure performance with NaNs. Then back to good values and measure it again.

Test current code, your first and last implementations.

Thanks,
Vladimir

On 6/22/12 7:34 AM, Roland Westrelin wrote:
> Hi Vladimir,
>
> Thanks for taking a look at this.
>
>> 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.
>
> Do you have a particular benchmark in mind? I checked reference_server and the only benchmark that make use of Math.pow() is specjvm98 but it does not seem critical to its performance: using the intrinsic or not doesn't make a difference.
>
> Here is a new webrev with uncommon traps:
> http://cr.openjdk.java.net/~roland/7177917/webrev.01/
>
> I also took you other suggestions into account.
>
>> 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.
>
> I agree that there could be a simpler/more efficient than d2l + l2d to check for an integer value.
>
> Roland.