On Wed, 10 Jan 2024 20:25:21 GMT, Alan Bateman <[email protected]> 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
