RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file updates [v3]

[Alan Bateman]

On Fri, 30 May 2025 17:43:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> 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.

When parked and there is a parkBlocker, blocked entering a monitor, or waiting in Object.wait, then it gets printed between the state and the stack trace. I think this is clearer. Note that the output isn't going to look at the same anyway as it's printing the object's identity hashcode rather than the address.

For the "locked" output then you may have a point, been back and forth on this. For synchronized methods then I think it's clearer when it is printed between the caller and synchronized callee. For synchronized blocks then it's clearer when to see which method has entered the monitor. Picking one means it's not clear in all cases but maybe people are just so used to "- locked" and don't notice. Can look at this again, it's trivial to swap between the two.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2116375673