RFR: 8250930: [TESTBUG] Some forceEarlyReturn00* tests failed due to compiler optimization
Chris Plummer
chris.plummer at oracle.com
Tue Aug 4 05:12:12 UTC 2020
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
>>>>>
>>>>>
>>
>>
More information about the serviceability-dev
mailing list