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
