RFR: 8280770: serviceability/sa/ClhsdbThreadContext.java sometimes fails with 'Thread "SteadyStateThread"' missing from stdout/stderr

[Chris Plummer]

On Sun, 30 Jan 2022 21:47:45 GMT, David Holmes <dholmes at 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