RFR: 8305919: java/lang/Thread/virtual/HoldsLock.java#id0 failed, ThreadInfo.getLockInfo() return null
Jaikiran Pai
jpai at openjdk.org
Tue May 2 05:51:14 UTC 2023
On Sun, 30 Apr 2023 18:18:09 GMT, Alan Bateman <alanb at 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
More information about the core-libs-dev
mailing list