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. > Sure, this was: 5047639: threadGroup.enumerate() ignores the Signal Dispatcher thread https://bugs.openjdk.org/browse/JDK-5047639 (2004) top ThreadGroup enumerate returns one less thread than ThreadMBean's getThreadCount. Notes: SignalDispatcher started by the VM, question on whether ThreadMBean should include system threads. Threads only added to a group if started with Thread.start() The test wants to ensure that thread group and mbean are consistent, it doesn't particularly look for any thread belonging to a particular group, but would be happy as long as all threads are either in both samples or neither. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14465#issuecomment-1596798164