On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk <[email protected]> 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
