RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception [v2]

[Richard Reingruber]

On Thu, 10 Jul 2025 08:16:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> That fixes the observed problem, but I find the existing test logic somewhat awkward. You only need a finally block to ensure something happens if an exception occurred - but here if you get an exception why do we care about joining the vthread? We don't know what the exception was or what it implies about the state of the vthread.

The test should notify(). Without the virtual thread will not terminate and stay there until the vm exits. This would influence (new) test cases as heap dumps would accumulate virtual threads from previous tests.

Btw this is another reason to call System.gc() before every test for fixing https://bugs.openjdk.org/browse/JDK-8361827

join() is helpful to find issues like the observed problem and to make sure the virtual thread's gone.

> 
> Also using wait/notify without a loop on the wait and checking a state variable is not the correct usage pattern and would be affected by spurious wakeups.

I've added the loop.

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

PR Comment: https://git.openjdk.org/jdk/pull/26213#issuecomment-3056690466