On Fri, 30 May 2025 18:15:52 GMT, Alan Bateman <al...@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@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
