On Tue, 20 Jan 2026 08:57:52 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 of some 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 "yyyy-MM-dd HH:mm:ss" as it is already used >> in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to >> preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a >> timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure >> if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a >> timestamp; > > Ivan Bereziuk 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 15 additional > commits since the last revision: > > - remove TimeStamp::No as it's not used. virtual should be flipped to > override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is > fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/1e69e598...5f1cefe0 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.) 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.) (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-3778803463
