RFR: 8250930: [TESTBUG] Some forceEarlyReturn00* tests failed due to compiler optimization

[Chris Plummer]

Hi Yasumasa,

The changes look good.

thanks,

Chris

On 8/3/20 6:38 PM, Yasumasa Suenaga wrote:
> Hi Chris,
>
> Thanks for your comment!
> I updated webrev:
>
>   http://cr.openjdk.java.net/~ysuenaga/JDK-8250930/webrev.01/
>
> This change produces infinite loop as below, it works fine.
>
>   1150:       8b 05 ae 2e 00 00       mov 0x2eae(%rip),%eax        # 
> 4004 
> <_ZZ100Java_nsk_jdwp_ThreadReference_ForceEarlyReturn_forceEarlyReturn002_forceEarlyReturn002a_nativeMethodE13dummy_counter>
>   1156:       85 c0                   test   %eax,%eax
>   1158:       74 f6                   je     1150 
> <Java_nsk_jdwp_ThreadReference_ForceEarlyReturn_forceEarlyReturn002_forceEarlyReturn002a_nativeMethod+0x50>
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2020/08/04 9:51, Chris Plummer wrote:
>> Hi Yasumasa,
>>
>> Although I don't doubt that it works, calling fgetc() seems like an 
>> odd way to resolve this issue. I had some internal discussions on how 
>> to safely cause an infinite loop. Something like the following should 
>> work:
>>
>> static volatile int dummy_counter = 0;
>>
>> while (dummy_counter == 0) {}
>>
>> volatile is important because it prevents gcc from assuming 
>> dummy_counter will always be 0.
>>
>> thanks,
>>
>> Chris
>>
>> On 8/2/20 10:55 PM, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> Please review this change:
>>>
>>>   JBS: https://bugs.openjdk.java.net/browse/JDK-8250930
>>>   webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8250930/webrev.00/
>>>
>>> Following tests which were compiled by GCC 10.2 failed.
>>>
>>>  - 
>>> vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn004/forceEarlyReturn004.java
>>>  - 
>>> vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java
>>>
>>> They have native module, and they are commented as below:
>>>
>>> ```
>>>    // execute infinite loop to be sure that thread in native method
>>>    while (always_true)
>>>    {
>>>        // Need some dummy code so the optimizer does not remove this 
>>> loop.
>>>        dummy_counter = dummy_counter < 1000 ? 0 : dummy_counter + 1;
>>>    }
>>>    // The optimizer can be surprisingly clever.
>>>    // Use dummy_counter so it can never be optimized out.
>>>    // This statement will always return 0.
>>>    return dummy_counter >= 0 ? 0 : 1;
>>> ```
>>>
>>> C compiler maybe eliminate this loop. We should not consider 
>>> compiler optimization at this point with other solution.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>
>>