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

[Chris Plummer]

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