On Sun, 30 Apr 2023 18:18:09 GMT, Alan Bateman <al...@openjdk.org> wrote:
> HoldsLock.java#id0 has been failing intermittently recently due to threads > left over from previous tests terminating. HoldsLock.java#id1 doesn't fail as > it runs in /othervm mode. The test uses ThreadMXBean::getAllThreadIds to get > the ID of all threads and calls ThreadMXBean::getThreadInfo on each thread. > If a thread from a previous test terminates then getThreadInfo returns null > and the test fails. > > The test can be trivially fixed to check for null but looking at it afresh, > the test can be simplified to use existing test infrastructure and to just > call ThreadMXBean::getThreadInfo on the carrier. The test can also be renamed > to make it clearer that it is testing a carrier threads wait for a virtual > thread. The old test includes a disabled test for Thread.holdsLock but there > is further VM work required before that is useful and it would be better to > develop new tests at part of that work. Hello Alan, these change look good to me. > The test uses ThreadMXBean::getAllThreadIds to get the ID of all threads and > calls ThreadMXBean::getThreadInfo on each thread. If a thread from a previous > test terminates then getThreadInfo returns null and the test fails. The test was problem listed only in `-Xcomp` but it wasn't clear why this issue would affect only `-Xcomp`, but then reading through the JBS issue, I can see that this failure was reproduced even without `-Xcomp` after the problem listing was done. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13738#pullrequestreview-1408429834
