RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means [v2]

[Chris Plummer]

On Thu, 30 Nov 2023 09:25:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> JDWP filters its own internal threads out of any thread lists it returns, so this may be a case of using two different API's with different views of the set of threads running.
>> 
>> I think the issue that Bernd is running into is a long standing anomaly between ThreadMXBean.getAllThreadIds() and the ThreadMXBean.getThreadInfo methods. The former uses a ThreadsListEnumerator with include_jvmti_agent_threads=false so it filters out the JVMTI agent threads. The latter doesn't do the filtering so if you have threadId of a JVMTI agent thread then you can get its thread info.
>
> I've created [JDK-8321095](https://bugs.openjdk.org/browse/JDK-8321095) to track the inconsistency that Bernd  brought up on whether JVMTI agent threads are hidden or not by ThreadMXBean.  It seems this inconsistency goes back a long way, to JDK 8 at least.

> > funfact: its not in the list
> 
> JDWP filters its own internal threads out of any thread lists it returns, so this may be a case of using two different API's with different views of the set of threads running.

JDWP does filter out its own threads (but not other JVMTI agent threads), but are we talking about JDWP here? It looks like Thread.print dcmd is producing the thread list that includes the JDWP threads, and as pointed out, ThreadMXBean.getAllThreadIds() does not include the JDWP threads (this is due to ThreadMXBean doing the filtering of JVMTI agent threads, not JDWP).

Note that `threadId` is clearly specified by ThreadMXBean, but there is no specification for the Thread.print output, so using unlabeled values from Thread.print as an argument to ThreadMXBean.getThreadInfo() seems somewhat presumptuous.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16791#discussion_r1410932828