RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file updates [v3]
Kevin Walls
kevinw at openjdk.org
Fri May 30 17:47:54 UTC 2025
On Thu, 29 May 2025 10:15:20 GMT, Alan Bateman <alanb at 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 at 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
More information about the serviceability-dev
mailing list