Also relevant are the jcmd commands that take an output filename. Those have been updated to take %p pid (JDK-8334492) and there was some thought given to adding time/datestamp. That didn't get completed but will hopefully still happen.
The title of JDK-8204681 might be out of date, it's not just hprof filenames, but all jcmd output files. More info in https://github.com/openjdk/jdk/pull/20568 Good to keep these things consistent where we can. 8-) Thanks Kevin -----Original Message----- From: serviceability-dev <serviceability-dev-r...@openjdk.org> On Behalf Of David Holmes Sent: Friday, January 31, 2025 2:58 AM To: Larry Cable <larry.ca...@oracle.com>; Kemper, William <kemp...@amazon.com>; serviceability-dev <serviceability-dev@openjdk.org>; hotspot-runtime-...@openjdk.org Subject: Re: Proposal to change the behavior of the timestamp place holder (%t) in log file paths On 31/01/2025 4:03 am, Laurence Cable wrote: > On 1/30/25 9:42 AM, Kemper, William wrote: >> >> Thank you all for your comments. We've gotten by using the pid (%p) >> as a means of grouping log files from a process. The log messages >> themselves include the uptime, so having the start time of the JVM in >> the file name has not been useful (and it would be trivial to add in >> from startup scripts). I take your points about using the >> modification time of the files and will consider this. >> > > is not also the case that "trivial to add in from startup scripts" > also true for creation time? > > perhaps propose a new substitution variable instead of redefining the > existing one? > > e.g: %c There has been some recent discussion (which I can't locate) about enabling various filename substitutions that match with the different Unified Logging timestamp decorators. Also Zhengyu just filed JDK-8349083. David > - Larry > >> --------------------------------------------------------------------- >> --- >> *From:* Laurence Cable <larry.ca...@oracle.com> >> *Sent:* Thursday, January 30, 2025 9:14:53 AM >> *To:* Kemper, William; serviceability-dev; David Holmes; hotspot- >> runtime-...@openjdk.org >> *Subject:* RE: [EXTERNAL] Proposal to change the behavior of the >> timestamp place holder (%t) in log file paths >> CAUTION: This email originated from outside of the organization. Do >> not click links or open attachments unless you can confirm the sender >> and know the content is safe. >> >> >> >> On 1/29/25 5:56 PM, David Holmes wrote: >> > Adding back serviceability-dev >> > >> > David >> > >> > On 30/01/2025 11:55 am, David Holmes wrote: >> >> Plus one to what Kevin says. The current specified behaviour seems >> >> to me to be what would be generally desired. If there is a desire >> >> for a different kind of timestamp to be used then a proposal to >> >> add that would be more appropriate I think. I seem to recall >> >> something fairly recent about expanding the notion of "timestamp" that >> >> can be used here. >> >> +2 for Kevin and David's observations; changing the timestamp from >> +JVM >> start time to create time, removes valuable and otherwise >> unobtainable (correlation) metadata from the logfile names, file >> creation and modification time is available from the underlying O.S >> filesystem if needed. >> >> Rgds >> >> - Larry >> >> >> >> >> David >> >> >> >> On 29/01/2025 7:24 pm, Kevin Walls wrote: >> >>> 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 >> >>> >> >> >> > >> >
