Async-profiler: support variable output file name using a placeholder

[ryenus]

Regarding the output file name specified here:

-agentpath:/path/to/libasyncProfiler.so=start,threads,svg,event=cpu,file=/path/to/profile_%.svg

It's a bit tedious, or error prone, for one to remember to replace the file name if the specified file already exists, otherwise it seems the existing file would be overwritten.

I wonder if it's possible to dynamically generate a file name? For example, we can treat the '%' character as a placeholder (or anything else suitable), so that a unique file name can be generated by replacing the '%' at runtime? Assuming a file named profile_9.svg already existed, then the next file name can be profile_10.svg.

[apangin]

Yes, it should not be difficult to generate file name from a pattern in async-profiler,
but I wonder why doesn't standard shell substitution work for you?

[ryenus]

Well, that's when the debug option is not set from a shell, or cannot be easily set, such as:

1. when working in an IDE, e.g. Eclipse or IDEA, I have to manually modify the debug configuration if I need to compare the output against previous executions.
2. in a large app that I work on, the java process is launched via a wrapper, so the debug option is set in a properties file, for which it cannot be set from the command line, even though the wrapper can be launched from the shell.

There're the two scenarios that I'm familiar with, maybe there're more.

[apangin]

OK, I'll consider this feature for the next release.

[oehme]

We would benefit from this a lot too - When profiling Gradle builds, a lot of additional JVMs are forked (for compilation, running tests etc). We'd like to instrument them all and aggregate the results into one overall profile. We can't compute a file name up-front for all the potentially spawned processes. Instead it would be great if we could just pass a directory and have async-profiler generate file names. JFR does this by using the process ID as the file name.

[apangin]

I committed the fix that expands

• %p to the process id;
• %t to the timestamp yyyyMMdd-hhmmss

One questionable thing with the timestamp pattern is - when I run profile.sh -d duration actually two files are produced: the first for the start command, and the second for the stop. Not a big problem though - I'll address it separately.