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

Reply via email to