Hi,

Just checking, but are they sure that's what they want? 8-)

This relates to files from unified logging, like java -Xlog:gc*:file%t.out 
...creates:  file2025-01-28_21-43-53.out and -Xlog:help says, "If the filename 
contains %p, %t and/or %hn, they will expand to the JVM's PID, startup 
timestamp and host name, respectively."

(Administratively, I think unified logging is under the runtime group, cc'd.)

Using the JVM start time, across all log files, identifies the set of files 
that come from the same process.  They will generally sort together when 
viewing a directory.  If a single file gets copied around, it can still be 
traced back in its group.   When there are multiple sets of logs in the same 
directory, the sets should still sort together.   I see the filename purpose as 
to identify the log, or set of logs.


Using a new timestamp for each file, the filenames do not identify the files as 
being part of the same run.  They may sort together, but may not if another log 
series is in the same directory, and once separated it's hard to regroup them.

Using the pid as well will help, but if we see a lot of low-numbered PIDs then 
this won't be unique. (With the current startup timestamp, you will probably 
use %p for pid in the file as well, in case JVMs start at the same moment.)

Thanks
Kevin



From: serviceability-dev <serviceability-dev-r...@openjdk.org> On Behalf Of 
Kemper, William
Sent: Tuesday, January 28, 2025 7:54 PM
To: serviceability-dev@openjdk.org
Subject: Proposal to change the behavior of the timestamp place holder (%t) in 
log file paths


The timestamp place holder in a log filename currently expands to the startup 
time of the JVM. When the log is rotated, the filename containing this 
timestamp is suffixed with a file number. My colleagues had expected the 
placeholder to be evaluated when the current log file is rotated. They expected 
the name of each rotated file to indicate the time the file was created. I 
think this expectation is not unreasonable, so I wanted to discuss the 
possibility of changing how/when the timestamp placeholder is evaluated. If 
there is any appetite for a change like this, I am willing to do the work. I 
would prefer to sort out the details before coding anything, rather than 
discussing them in a surprise pull request.



Thank you for reading,

William

Reply via email to