This test was recently dialled down via JDK-8323002 but it still makes slow progress on some test machines, esp. macox-x64-debug builds. The issue is that the the sampling of the target thread is skewed towards the unmounted case so the target thread is disabled from being scheduled and doesn't make progress. The test is re-worked to use a barrier so that the main thread and target virtual thread run in lock step. This allows the virtual thread to make progress at each iteration and also increases the chances of sampling the stack trace at around the time that the target thread transitions from being unmounted (due to the Thread.yield) and parking while pinned.
------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/17353/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17353&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323296 Stats: 53 lines in 1 file changed: 47 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/17353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17353/head:pull/17353 PR: https://git.openjdk.org/jdk/pull/17353