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

[Yasumasa Suenaga]

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