On Mon, 28 Jun 2021 13:07:21 GMT, Kevin Walls <kev...@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
