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

Yi Yang yyang at openjdk.java.net
Tue Jun 29 03:30:06 UTC 2021


On Mon, 28 Jun 2021 13:07:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> If so (and if we don't discover more tools that prefer hex for thread IDs!), then we want to be consistent, so in addition to the native/built in implementation, we should also update:

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java
..to keep the SA implementation in sync. It would be odd to have thread dumps looking more different depending on what generated them.

> And if changing that, also change:
test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java

Thanks for the comments! I will change the corresponding SA implementation and tests.


> > Hi,
> > If you attach WinDbg on Windows to a JVM, you might be glad of the nid=0x... format as that is its choice of base for the thread ids.
> > So this depends on your tools. Maybe frustrated top users outnumber happy WinDbg users for the JVM, and maybe they don't. Maybe this change delights some users and frustrates others.
> 
> Why not do it platform dependent then? This would make sense especially since the type is opaque. Let each platform handling printing. Windows can hex-print its DWORD thread id. Linux can print its kernel LWP. And platforms where the thread id is 64bit, or a structure, can print that.
> 
> For now default implementations could live in `os::Windows::print_thread_id(thread_t)` and `os::Posix::print_thread_id(thread_t)`, respectively.

Will it be too heavy to add a platform-dependent implementation for this small function? As Kevin said, maybe this change delights some users and frustrates others. But since POSIX is the vast majority of users, it may be a better choice to adapt to them. Just IMHO..

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

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


More information about the serviceability-dev mailing list