Loop strip mining to decreases safepoint poll frequency

[Roland Westrelin]

> This affects only counted loops too, right?

Yes.

> I would expect -XX:+UseCLS and -XX:LSM=# to be independent. That is, behave like
> this:
>
>   a) -XX:+UseCLS -XX:LSM=0:
>     what we have now; counted loops with safepoints
>
>   b) -XX:-UseCLS -XX:LSM=0:
>    no safepoints in counted loops -- strip mining is useless?
>
>   c) -XX:+UseCLS -XX:LSM=<positive>:
>    strip-mined counted loops with safepoints
>
>   d) -XX:-UseCLS -XX:LSM=<positive>:
>    no safepoints in counted loops -- strip mining is useless?
>
> My concern is that latency-oriented people do run with -XX:+UseCLS in their
> configurations, and current patch seems to disable loop strip mining for them!

I don't have a strong opinion on this. C2 now ignores UseCLS entirely
and only checks LSM:

LSM=0, no safepoint = -XX:-UseCLS
LSM=1, safepoint in every iteration = -XX:+UseCLS
LSM>1, strip mining

so argument parsing is expected to adjust the LSM value from the UseCLS
value and what you're suggesting translates to:

  if (UseCountedLoopSafepoints && LoopStripMiningIter == 0) {
    LoopStripMiningIter = 1;
  } else if (!UseCountedLoopSafepoints && LoopStripMiningIter > 0) {
    LoopStripMiningIter = 0;
  }

in Arguments::check_vm_args_consistency()

Roland.