RFR: 8349083: Factor out filename handling code from logging

[Zhengyu Gu]

On Wed, 12 Feb 2025 06:26:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm not sure how best to handle the "%t". My view was that we would standardize "%t" to mean the timestamp of when the VM started, but I guess if there are pre-existing uses of "%t" that mean something different then that would be a problem. Note that share/utilities/ostream.cpp also has similar logic for creating log file names with %p and %t.
> 
> My concern is your current code re-stringifies the timestamp on every call, whereas the logging code only created the vm_startup_time_str once. When the timestamp is being passed in, memoizing it is problematic - whereas if you know it is the VM startup time it is no problem at all. The strings for %p and %hn should also be memoized, though logging does not currently do that.
> 
> It might be clearer to take a timestamp-string rather than the timestamp and then have utility methods to get `vm_startup_time_str()` and `current_time_str()`, where the former at least can cache the string for future use. The same could be done for `host_name_str()` and `pid_str()`. The caching for idempotent strings doesn't need to use locking, just a `release_store` with a paired `load_acquire`.

Hi @dholmes-ora 

I am *not* trying to standardize timestamp in this PR, but a simple refactor so that we don't have wildcard parsing and replacing code all over the places.

I am curious why re-stringifying the timestamp and host name are concerns? obviously, the code is not on any hot paths.

If we decide to standardize timestamp, then we should hoist initializing `vm_startup_time` code up from unified logging and stringify timestamp and host name cache here, just as unified logging does right now early in bootstrap cycle (`Threads::create_vm()`), therefore, we don't need any memory barriers to use the cached strings.

Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23410#issuecomment-2654128259