RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file updates

[Chen Liang]

On Sat, 24 May 2025 06:57:56 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

src/hotspot/share/classfile/javaClasses.cpp line 2241:

> 2239: }
> 2240: 
> 2241: class jdk_internal_vm_ThreadLock: AllStatic {

All other class for java classes are declared in javaClasses.hpp. Wonder if runtime would accept a class declared in the cpp file.

src/hotspot/share/classfile/javaClasses.cpp line 5519:

> 5517: oop java_util_concurrent_locks_AbstractOwnableSynchronizer::get_owner_threadObj(oop obj) {
> 5518:   assert(_owner_offset != 0, "Must be initialized");
> 5519:   return obj->obj_field_acquire(_owner_offset);

Is this a preexisting bug? If yes we should have this fixed in a separate patch so it is eligible for backporting, etc.

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 247:

> 245:         var jsonWriter = new JsonWriter(textWriter);
> 246: 
> 247:         jsonWriter.startObject();  // top-level object

Is this anticipated to be used in early bootstrap so we use `startObject` `endObject` instead of using functional code or try-with-resources that create scopes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2106087716
PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2106087007
PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2106088093