On Tue, 28 Nov 2023 16:59:53 GMT, Bernd <d...@openjdk.org> wrote: >>> btw for the following (system/native/runtime/embryotic) Reader thread >>> tseems to be no java method marked "native" on the stack, what case is that? >>> >>> ``` >>> "JDWP Event Helper Thread" #22 daemon prio=10 os_prio=0 cpu=0.00ms >>> elapsed=65.02s tid=0x000001fc4f7e9970 nid=0x32e0 runnable >>> [0x0000000000000000] >>> java.lang.Thread.State: RUNNABLE >>> >>> "JDWP Command Reader" #23 daemon prio=10 os_prio=0 cpu=0.00ms >>> elapsed=65.02s tid=0x000001fc4f7ea480 nid=0x69c4 runnable >>> [0x0000000000000000] >>> java.lang.Thread.State: RUNNABLE >> >> The debugger uses JVMTI RunAgentThread to create its own threads. These >> threads are partly hidden, at least from some APIs. However, I think your >> comment does bring up the question of threads that don't have any Java >> frames, as in JNI attached threads that haven't called into Java code. This >> method has never specified that case, need to think we should try to specify >> it now. > > Well.. it has to do in so far, that those threads are not hidden - the > ThreadInfo sees it and says "isNative". But ok if this is not expected, then > indeed it does not need to be documented.
> seems to be no java method marked "native" on the stack, what case is that? A native thread that is attached to the VM but is not currently executing any Java code. > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16791#discussion_r1408818581
