RFR(M): 8223051: support loops with long (64b) trip counts

[Roland Westrelin]

> Putting these together, and choosing a round number
> which prioritizes concern (b) by moving closer to the
> limit of (a), if I had one more run to do I’d choose
> -XX: StressLongCountedLoop=20000000.
>
> If I were to do multiple runs, I might choose vary that
> stress parameter by adding and subtracting a couple
> of zeroes:
>
> -XX: StressLongCountedLoop=200000
> -XX: StressLongCountedLoop=2000000
> -XX: StressLongCountedLoop=20000000
> -XX: StressLongCountedLoop=200000000
> -XX: StressLongCountedLoop=2000000000

FWIW, I ran my own tests with -XX: StressLongCountedLoop=10000. Tobias
runs did catch failures I didn't run into.

> Separately from those issues, we know that the stress mode
> converts 32-bit loops into 64-bit loops, which then re-nest
> using the new logic.  But, are we confident that this re-nesting
> works?  Roland did some manual testing to make sure the
> test works as intended, but it would be good to run the above
> stress tests with some sort of logging that ensures that there
> are at least “lots and lots” of successful 32-to-64 loop conversions.
> If those loop conversions fail (staying at 64 bits) the tests will
> pass, but they won’t be testing what we need to be testing.

What about using the new statistics?
A CTW run of the base module reports: long loops=11/36
A CTW run of the base module with -XX:StressLongCountedLoop=1000 reports: long loops=3271/3410

Granted, the first counter is only incremented once the loop nest is
created but not when the inner loop is converted to a counted loop. On
another run with a third counter incremented on counted loop creation:

2889/2971/3106

(that not all created inner loops are transformed to counted loops is
strange. Maybe some become dead between the 2 steps.)

Roland.