RFR: 8323296: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id1 timed out

[Jaikiran Pai]

On Wed, 10 Jan 2024 20:25:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 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 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.

test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java line 65:

> 63:             for (int i = 0; i < iterations; i++) {
> 64:                 // wait for main thread to arrive
> 65:                 barrier.await();

Given the goal of this test, which is "Stress test Thread.getStackTrace on a virtual thread that is pinned", shouldn't this `barrier.await()` be a few lines below, inside the `synchronized (GetStackTraceALotWhenPinned.class)` block, just before it parks itself? That way, the main thread when it too reaches the barrier and when it next issues a getStackTrace() call, the chances of the other thread being pinned would be high(er)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17353#discussion_r1448894710