Request for reviews (XS): 7039652: Performance regression after 7004547 changes
Tom Rodriguez
tom.rodriguez at oracle.com
Thu Apr 28 12:34:59 PDT 2011
Seems ok.
tom
On Apr 27, 2011, at 4:17 PM, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/7039652/webrev
>
> Fixed 7039652: Performance regression after 7004547 changes
>
> In the test case initial stride is -8 so the loop is unrolled only once after 7004547 changes moved next condition to the beginning of policy_unroll() method:
>
> // Check for stride being a small enough constant
> if (abs(cl->stride_con()) > (1<<3)) return false;
>
> Before 7004547 changes that check was done at the end of policy_unroll() and the method returned 'true' if there were a lot 'xor' nodes in the loop regardless the stride check. As result the loop in the test case was unrolled twice.
>
> The stride check serves additional purpose to limit unrolling to 16 (when initial stride is '1'). But as the test shows it may prevent legit unroll with bigger stride.
>
> The fix is to use unrolled_count() to limit unrolling and use the stride check only for initial stride value. I don't understand why there is such limit on stride but it is for an other investigation (RFE).
>
> I ran refworkload and don't see any affects from this fix.
More information about the hotspot-compiler-dev
mailing list