On Fri, 30 May 2025 17:43:15 GMT, Kevin Walls <kev...@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@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
