On Sun, 30 Jan 2022 21:47:45 GMT, David Holmes <dhol...@openjdk.org> wrote:
> That seems bizarre. If this is a dump from our Java launcher then there
> should be no other threads created before the one that loads the JVM.
Maybe they are invisible threads that Windows creates on thread launch that are
deleted soon after startup. Or maybe it has little to do with thread
creation/deletion, and the numbering given to threads depends on other factors.
> That said I'm a little surprised we are doing "kernel debugging" here and so
> the "engine id" comes into play. But that said shouldn't we be using the
> stable "system id" for the threads not this "engine id" ?
I'm not sure. This appears to be unique to Windows. For Linux the
`javathread.printThreadIDOn()` call boils down to the following in
LinuxThread.java:
public String toString() {
return Integer.toString(lwp_id);
}
For BSD:
public String toString() {
return Integer.toString(thread_id);
}
For Windows:
public String toString() {
return Long.toString(getThreadID());
}
/** Retrieves the thread ID of this thread by examining the Thread
Information Block. */
private long getThreadID() {
if (!gotID) {
id = debugger.getThreadIdFromSysId(sysId);
gotID = true;
}
return id;
}
I'm not sure why it is done this way. Note I introduced nothing new with how
clhsdb deals with Thread IDs when I added the threadcontext comment. The
following commands can all run into this issue:
- dumpreplaydata
- dumpideal
- dumpcfg
- dumpilt
- where
- thread
- threads (which prints the thread id so you can pass it to other commands)
So this is an old issue. If you want I can file a separate CR for it. I don't
think it makes any sense to address it as part of this bug fix.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7259
