On Thu, 13 Jul 2023 02:13:54 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> After [JDK-8308232](https://bugs.openjdk.org/browse/JDK-8308232), both the >> test and the debuggee shared the same waittime of 5 minutes. The test would >> wait up to 5 minutes for the expected prompt, but the debuggee would also in >> some cases wait 5 minutes before generating the prompt, which sometimes was >> just a bit too late. Before >> [JDK-8308232](https://bugs.openjdk.org/browse/JDK-8308232), the debuggee >> would wait at most 2 minutes before generating the prompt, so it was always >> generated in time. >> >> The main issue is that after the while loop checks that there are still >> uninterrupted threads remaining, the last of the threads is interrupted >> before the wait() call is made. This means wait() won't return until it >> times out, and by then it is too late, and the test side has already timed >> out waiting for the prompt. >> >> The fix is to widen the synchronized block so the count of not interrupted >> threads remains correct until `wait()` is entered. The other choice was to >> refetch the count after entering the synchronized block, which is what I did >> for the initial fix, but widening seems a better choice so no refetch is >> needed. >> >> For details see >> https://bugs.openjdk.org/browse/JDK-8310551?focusedCommentId=14594838&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14594838 >> >> Tested with 300 runs each on linux-x64 and linux-aarch64 with -Xcomp options >> that reproduced the issue, and then again with no options. > > Chris Plummer has updated the pull request incrementally with one additional > commit since the last revision: > > Suggestion from David. Widen synchronized block so it is not necessarry for > notInterrupted to be atomic. Thanks Serguei and Kevin! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14817#issuecomment-1636247100
