On Wed, 14 Jun 2023 09:30:49 GMT, Kevin Walls <kev...@openjdk.org> wrote:
> This test fails when additional threads are created, as it compares thread > lists from different sources and sees a mismatch. > > It needs to tolerate some threads with certain names appearing, e.g. JVMCI > and ForkJoin threads. If there are extra threads in the thread ID list from > the ThreadMBean, remove them from the thread count before comparing. > > When it fails, additionally print the ids and names of threads that it got > from the MBean. > > I found the test quite confusing, the naming of thread counts, arrays of > threads, and arrays of thread stacktraces from different sources, so have > renamed some things. Thanks for the comments and reviews. I did look at the history and this test exists because of previous confusion about thread groups, where the top thread group and the MXBean thread lists could be different. So if this test creates new threads and checks they are in both lists, it loses the original purpose as I read it. I'm not saying it's a great test. But it successfully monitored that problem since 2004, and lasted surprisingly well even before being moved to an "othervm" ! If there's any mole-whacking, I think the new logging should make it easy to see the name of the mole, and if it's a thread that's expected to appear possibly between the observations, then it can be added to the list. It is just those two new things, JVMCI and ForkJoinPool, which are known to fool it so far. We should make this change and watch for moles appearing, or indeed disappearing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14465#issuecomment-1592680861
