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/df6de4c1...5f1cefe0 Lots of duplication in the execute methods, of the same common condition around calling print_local_time... That's a reason in favour of the jcmd driver printing the timestamp itself so it can be done in one place, if required. (The local attach API is not slow enough to cause a problematic latency in when the timestamp was printed, and when the command was actually run. Certainly not compared to the current workaround of running: "date; jcmd ...") To deal with commands that already show a timestamp, if JCmd.java is where the timestamp is printed: if jcmd can send a parameter over the new attach api to the diagnostic command, then it can send a boolean "i have already printed a timestamp". Then only an existing command which already prints a timestamp would need to check. Or separately in David's note earlier: "And rather than add timestamp printing code to each dcmd it would make more sense to me to have a global dcmd flag that says "print a timestamp" (with a given format). That way users opt-in and we don't have to remember to add this for new Dcmds." This relates to if the printing is done in the native code, and as I read it this was about having a flag checked before the individual execute methods, so it can be done in one place (not sure but maybe this would be DCmd::Executor::parse_and_execute()). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3773270519
