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

[Chris Plummer]

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.

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