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
