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

[Yasumasa Suenaga]

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.


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
>>>>
>>>>
> 
>