On Thu, 29 May 2025 10:15:20 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and >> jcmd Thread.dump_to_file to include thread state and lock information. Also >> update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a >> description of the JSON format dump as that format is intended to be >> parseable/read by tools. >> >> This PR is dependent on >> [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that >> PR, the changes accumulated in the loom repo, and have been split up to make >> it easier to review. >> >> The changes include some re-implementation of ThreadDumper. This is because >> it used PrintStream and didn't fail if there was an I/O error, e.g. file >> system full. Furthermore, the indentation to pretty print the json was >> fragile and hard to maintain so this is changed to use a supporting writer >> class to do this. >> >> Test coverage is significantly expanded, including updating the test library >> that is used by several tests to parse the thread dump. >> >> Testing: tier1-6 > > Alan Bateman has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains five additional > commits since the last revision: > > - Temp fixed until fixed in pull/25425 > - Sync up from loom repo, includes review comments > - Merge branch 'pull/25425' into JDK-8356870 > - Merge branch 'pull/25425' into JDK-8356870 > - Initial commit src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 180: > 178: } > 179: > 180: private static void dumpThread(Thread thread, TextWriter writer) { On the non-json text format for locks: here we're creating a new comment-like style: // parked on ..etc... In the regular Thread.print we always used a "-" prefix, and always printed the frame, then the relevant locks, like: at ThreadsMem$2.run(ThreadsMem.java:38) - waiting to lock <0x0000000630817da0> (a java.lang.Object) at java.lang.ref.ReferenceQueue.remove(java.base@25-internal/ReferenceQueue.java:215) - locked <0x0000000630802350> (a java.lang.ref.ReferenceQueue$Lock) Could we use the same? We have a lot of history reading the established style. 8-) Can we match the old-style "waiting to lock" rather than "waiting on" ? I realise I'm asking to move the printing of "waiting to lock" into the loop over the stackframes, and it affects various tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2116330396
