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

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Jun 26 12:04:01 PDT 2012

Roland Westrelin wrote:
> Hi Vladimir,
>>> I'm not sure I understand what you mean by: "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.".
>> Your first implementation does not deoptimize NaN cases so I wanted to see if there is difference in performance.
> Sorry. It's unclear to me. Is there anything beyond these:
>>> I wrote a micro benchmark that:
>>> - chooses 1 million "good" random values for pow
>>> - time the computation of pow for the 1 million values
>>> - force the uncommon trap and recompilation
>>> - do the measurement again with the same 1 million values
> that you wanted to see measured?

- do the measurement with "bad" 1 million values when pow produces NaN

but it is not important so we can skip it.

>>> same thing with exp and I did the measurement with the previous and current version of the code but I don't see any difference.

I also do not see difference between your 2 implementations with your test. I 
still prefer second (with uncommon trap) since it generate simpler code for 
normal case.

>> Did you verify that during first round you did not get NaN and deoptimized code already? There should be a difference. Did you pre-generate randoms values?
> Yes to both questions.
> Here is the micro benchmark:
> http://cr.openjdk.java.net/~roland/7177917/webrev.02/test/compiler/7177917/Test7177917.java.html

The test is good. I thought that a big array will not fit into CPU's cache and 
will affect performance, but it does not - hardware prefetch really works in 
modern CPUs :)

Your changes are good. You can push then if you think they are ready and well 


> Roland.

More information about the hotspot-compiler-dev mailing list