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

[David Holmes]

Looks good to me.

Thanks,
David

On 4/08/2020 3:13 pm, Yasumasa Suenaga wrote:
> On 2020/08/04 14:12, Chris Plummer wrote:
>> 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.
> 
> Ok, I'm waiting for 2nd reviewer for this change.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
>> 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
>>>>>>>
>>>>>>>
>>>>
>>>>
>>
>>