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

[Yasumasa Suenaga]

Submit repo reported build failure on macOS.
Can you share details?

   Job: mach5-one-ysuenaga-JDK-8250930-1-20200804-0139-13140081


Thanks,

Yasumasa


On 2020/08/04 10:38, 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
>>
>>