RFR: 8268425: Show decimal nid of OSThread instead of hex format one [v3]

Kevin Walls kevinw at openjdk.java.net
Tue Jun 29 11:52:09 UTC 2021


On Tue, 29 Jun 2021 03:42:32 GMT, Yi Yang <yyang at 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
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use UINT64_FORMAT; change SA and test impl

Maybe we can't make everybody happy, but what we have now is a good improvement (for many/most).
I tested with the SA change, the test passes, and manually on Windows I ran jstack and jhsdb jstack, jhsdb clhsdb.

> Will it be too heavy to add a platform-dependent implementation for this small function?...
I think so.
I think this looks good now.

I don't think it's a change we should backport, or at least not quickly, out of concern for people/tools who might be parsing this output.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449


More information about the serviceability-dev mailing list