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

[Chris Plummer]

On 8/3/20 9:43 PM, Yasumasa Suenaga wrote:
> Hi Chris,
>
> On 2020/08/04 12:18, Chris Plummer wrote:
>> Hi Yasumasa,
>>
>> I'm not sure yet. I'm waiting for a answer from the build support 
>> team. It looks like some sort of sporadic build failure unrelated to 
>> your changes. Only one of several macosx builds failed. You might 
>> just want to try to submit the changes again.
>
> I resubmitted the change, then it succeeded 
> (mach5-one-ysuenaga-JDK-8250930-2-20200804-0330-13141411).
> It might be sporadic failure as you said.
>
> I will push it to jdk/jdk when you get answer from the build support 
> team.
>
Still not 100% what went wrong, but it's clear it's not due to your 
changes. You can push, but you still need to get a 2nd reviewer.

thanks,

Chris
>
> Thanks,
>
> Yasumasa
>
>
>> thanks,
>>
>> Chris
>>
>> On 8/3/20 7:41 PM, Yasumasa Suenaga wrote:
>>> 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
>>>>>
>>>>>
>>
>>