RFR: 8303916: ThreadLists.java inconsistent results
Kevin Walls
kevinw at openjdk.org
Mon Jun 19 09:07:16 UTC 2023
On Wed, 14 Jun 2023 09:30:49 GMT, Kevin Walls <kevinw at 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
More information about the serviceability-dev
mailing list