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

[Kevin Walls]

On Fri, 30 May 2025 18:15:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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 summary/state (first line) and the stack trace. I think this is a bit clearer that printing it after the top frame but okay to change. Note that the output isn't going to look the same as the traditional thread dump as it prints 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.

Thanks yes I do like this update -  I think it reads how we are used to seeing these things (without aiming to be exactly the same format as Thread.print). 

(oops my comment suggested waiting on, and waiting to lock, are the same, but they are not)

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

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