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

[Vladimir Kozlov]

I assume it is latest webrev:

http://cr.openjdk.java.net/~roland/8223051/webrev.02/

First, I think this change should wait until JDK 16 (which will be very soon).
And I need more time to look through changes.

In original RFR, Roland, you showed that loop will be transformed into:

for (long l = long_start; l < long_stop; ) {
   int int_stride = (int)long_stride;
   int int_stop = MIN(long_stop - l, max_jint - int_stride);
   l += int_stop;
   for (int i = 0; i < int_stop; i += int_stride) {
   }
}

My question is about 'l += int_stop'. Do you optimize only loops which does not have any references to 'l' inside loop?
Will you process expressions like (l + i) in inner loops?

Thanks,
Vladimir

On 6/3/20 11:31 PM, Tobias Hartmann wrote:
> Hi Roland,
> 
> On 03.06.20 11:16, Roland Westrelin wrote:
>>>>> Tobias might wish to run some regression tests on the final changes.
>>>
>>> I've submitted some testing. Will report back once it finished.
>>
>> Thanks.
> 
> I'm seeing some failures with -XX:StressLongCountedLoop=429496729. Will follow-up offline.
> 
>>> loopnode.cpp:
>>> - line 504: "check_stride_overflow" is already in 8244504
>>
>> Right but the one in this webrev is for longs so doesn't have the same
>> signature.
> 
> Right and as John already mentioned it's probably not worth using templates here.
> 
>>> loopnode.hpp:
>>> - line 1462: Shouldn't _loop_invokes/_loop_work also be volatile and be incremented atomically?
>>
>> I think so too. That they are not incremented atomically implies nobody
>> uses them AFAICT. If we want all of them to be handled correctly then
>> someone needs to go over Compile::print_statistics() and all methods it
>> calls.
> 
> Right that's out of scope of this change.

We never consider to have accurate statistic counters. The main criteria is to have them as cheap as possible execution 
wise. And using atomics was expensive back in old days. Not today.

Thanks,
Vladimir

> 
> Best regards,
> Tobias
>