RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4]

[Thomas Stuefe]

On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

>> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
>> Adding a timestamp to the output would add value for those debugging JVM data.
>> 
>> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
>> 
>> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t":
>> 
>> jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename
>>                         ^^^^
>> 
>> * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`)
>> * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility.
>
> Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change flag name from -T to -t

Just piling on, sorry for bikeshedding...

> OK thanks, yes not changing all the dcmds in https://github.com/openjdk/jdk/pull/29325/files is nice. 8-)
> 
> Regarding whether JCmd.java could do the timestamp, or we need to change the native side: Yes a problem there is the timestamp duplication issue: if JCmd can optionally print a timestamp as a header before running the command, that timestamp info is duplicated in Thread.print.
> 
> But is it really that bad, and is it worth the extra argument processing? (In diagnosticFramework, we need to introduce parse_common options just for this one flag.)

I agree.

> 
> If JCmd.java does the timestamp: if you opt-in to JCmd with a timestamp, you would get the new timestamp in the new format, followed by the old Thread.print timestamp in its format... This avoids the new complexity in the native code, and keeps the new timestamp handling in the simple JCmd.java wrapper. It sidesteps the problem that Thread.print uses an arguably "wrong" format. (An in time, maybe Thread.print would migrate to not printing a timestamp.)

I would prefer if the hotspot did write the timestamp, because 
1) The time may run differently on the jcmd side (e.g. target runs on a container on Windows or MacOS, or if we ever add remote capabilities to jcmd)
2) adding it to the hotspot will automatically work for every version of jcmd (e.g., I usually just call "jcmd" and use whatever jcmd tool happens to be on the path on that particular machine, but no guarantee it comes from the target VM)

> 
> (JCmd could optionally print a duration at the end as was hinted somewhere earlier. Heap dumping prints its own time taken, but few other commands consider it interesting.)

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3788641543