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

[John Rose]

On Aug 25, 2020, at 6:37 AM, Roland Westrelin <rwestrel at redhat.com> wrote:
> 
> 
>> 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.)

Yes, that’s the sort of manual testing I was referring to.
The numbers you show are a reasonable value of “lots and lots”
for a CTW run.  Who knows what the conversion rates are
for real applications driven by profiles.  I’m curious what
they are but I suppose we can live without them.  We don’t
have AFAIK a way to set up a special cumulative report
for a tier of testing on those parameters.  I guess we are
several levels of improvement short of being able to set up
a probe across a set of tests and roll up statistics from it.

So, with Tobias running those extra tests (the “20s”)
we are more than good.

Thanks!

— John