On Thu, 10 Jun 2021 02:07:36 GMT, Yi Yang <yy...@openjdk.org> wrote:
> From users' perspective, we can find corresponding os thread via top
> directly, otherwise, we must convert hex format based nid to an integer, and
> find that thread via `top -pid <pid>`. This slightly facilitates our
> debugging process, but would obviously break some existing jstack analysis
> tool.
>
> Jstack Before:
>
> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s
> tid=0x00007f967000b000 nid=0x12e67 runnable
>
> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s
> tid=0x00007f967000c000 nid=0x12e68 runnable
>
> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s
> tid=0x00007f967000e000 nid=0x12e69 runnable
>
> Jstack After:
> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490
> nid=117707 runnable
>
> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20
> nid=117708 runnable
>
> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140
> nid=117709 runnable
>
> Top:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
> 71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
> 50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
> 99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
Changes requested by stuefe (Reviewer).
src/hotspot/share/runtime/osThread.cpp line 41:
> 39: // Printing
> 40: void OSThread::print_on(outputStream *st) const {
> 41: st->print("nid=%d ", thread_id());
thread_id is of an opaque type (eg pthread_t). I think we can reasonably assume
its numeric, but I would print it as an unsigned 64bit int just in case.
src/hotspot/share/runtime/osThread.cpp line 49:
> 47: case CONDVAR_WAIT: st->print("waiting on condition ");
> break;
> 48: case OBJECT_WAIT: st->print("in Object.wait() ");
> break;
> 49: case BREAKPOINTED: st->print("at breakpoint");
> break;
These cleanups don't seem to have anything to do with this change.
-------------
PR: https://git.openjdk.java.net/jdk/pull/4449
