The .jtr file of a jtreg test cases has several sections, one each for the jtreg action that was run during the execution of the test. The reporting in these section include useful information like what command initiated the action, the start time of the action, the elapsed time, the agent id (if it was run in an agent VM) and so on.

Some example sections look like:

#section:compile
----------messages:(7/297)----------
command: compile test/streams/FileDescriptorTest.java
reason: .class file out of date or does not exist
started: Fri Jul 26 00:56:01 UTC 2024
Mode: othervm
finished: Fri Jul 26 00:56:01 UTC 2024
elapsed time (seconds): 0.254

....

#section:main
----------messages:(7/232)----------
command: main FileDescriptorTest
reason: User specified action: run main FileDescriptorTest
started: Fri Jul 26 00:56:01 UTC 2024
Mode: othervm
finished: Fri Jul 26 00:56:01 UTC 2024
elapsed time (seconds): 0.042

Tests that fail sometimes require investigation what happened in the process in which the test was running. Sometimes that process is agent VM process and sometimes it's just a other VM process.
The agent id reported in those sections, several times help with identifying the process id of the agent JVM and that then helps check various logs that contain details about that process (like the dmesg output on linux might contain this process id when a OOM killer kills it for example).
However for other VM mode where jtreg launches a separate VM to run the test, it's not always easy or feasible to correlate that JVM to a process id, thus making it difficult to diagnose crashes, failures and such. In fact, even for agent VM, the presence of just the agent id in the section messages may not always be enough if the agent JVM has been terminated and thus the process id wasn't captured in the jps -l output.

The proposal here is the enhance the section messages to even include the process id of the process (either agent vm or other vm) that was used to execute the corresponding action. jtreg, internally, already has access to the process id and reporting this can help improve the ability to investigate unexpected test failures.