On Tue, 15 Aug 2023 23:03:31 GMT, Alex Menkov <amen...@openjdk.org> wrote:
> This is an attempt to fix suspicious code in the forceEarlyReturn002.java and
> un-problemlist it to see if the problem appear again.
>
> The test fails in "virtual thread factory" mode with timeout for unclear
> reason after it finished testing and performs cleanup process (debugger sends
> debuggee a command to exit, but debuggee doesn't receive the command).
> This is the only test which has this intermittent communication failures.
> The test was problem-listed, I was not able to reproduce the issue with 1000+
> runs.
>
> Debuggee creates a thread which executes tight infinite loop in native code
> (in "virtual thread factory" mode it's pinned virtual thread).
> The fix adds delays in the loop and adds new command to exit from native
> method after testing.
>
> Testing: 100 runs in "virtual thread factory" mode on all Oracle supported
> platforms.
Changes requested by lmesnik (Reviewer).
test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/libforceEarlyReturn002a.cpp
line 34:
> 32: extern "C" {
> 33:
> 34: static volatile bool wait_in_native = true;
The wait_in_native should be atomic or used inside raw monitors since it is
used by different thread.
-------------
PR Review: https://git.openjdk.org/jdk/pull/15301#pullrequestreview-1579623534
PR Review Comment: https://git.openjdk.org/jdk/pull/15301#discussion_r1295254839
