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

Reply via email to