[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means 
From:       Chris Plummer <cjplummer () openjdk ! org>
Date:       2023-11-30 16:33:23
Message-ID: QkfZGrZqoTFZ6Sn573mSlzhQqDOq1_RZzlcU8MJL0sg=.09fd0b6b-1f23-4592-97b3-287db1f4ad1b () github ! com
[Download RAW message or body]

On Thu, 30 Nov 2023 09:25:04 GMT, Alan Bateman <alanb@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


[prev in list] [next in list] [prev in thread] [next in thread]