There might be reasons to store multiple checkpoint images from a single application, e.g. if we’re running on different physical hosts (architecture and CPU features). Checkpoints could be also created from a differently warmed-up application, on regular intervals etc.

Right now, -XX:CRaCCheckpointTo=/my/path points to a directory with contents opaque to JVM. This directory is created (by JVM) if it does not exist, if it exists the contents is not wiped out, rather directly overwritten.

We can turn this into a pattern: -XX:CRaCCheckpointTo=/my/path/%x_%y_img will replace %x and %y and the final path will be /my/path/foo_bar_img. The path itself only generates semi-unique destination and has only informative value, helping the user to organize the images. If a placeholder stands for CPU features JVM does not validate that the bitmask stored in the image itself matches the pattern where it is loaded from.

Here is a list of available patterns:
* %%: single % character
* %a: architecture (x86_64 or aarch64)
* %f: CPU features hex string
* %u: UUID (version 4 = random)
* %t: checkpoint date & time in ISO-8601 in UTC, basic format (without separators) with second precision, e.g. 20250909T141711Z
* %T: checkpoint epoch time (second precision)
* %b and %B: process boot time (generation 1), same format as %t or %T
* %p: PID of checkpointed process
* %c: number of CPU cores
* %m: max heap size (-Xmx) in a user-friendly format - using G or M suffix
* %g: checkpoint generation (1 until we implement repeated checkpoints, 0 reserved for ‘unknown’)
* %r and %R: last restore time, same format as %t or %T. In case of generation 1 this is is the same as process boot time.

Numeric arguments (%p, %c, %g…) can use fixed width, padded with zeroes like this: %03g will produce 001.

Pattern is validated when the Java process is started (early failure).