[crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v7]

[Timofei Pushkin]

On Thu, 23 Oct 2025 12:46:50 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add README, truncate metric name, expose jdk.crac.internalResources

src/java.base/share/classes/jdk/internal/crac/Score.java line 67:

> 65:         int resources = 0;
> 66:         for (var p : Core.Priority.values()) {
> 67:             if (p.getContext() instanceof OrderedContext<?> octx) {

I would prefer a cast just to ensure we don't miss a resource, but for now this should be equivalent

src/java.base/share/native/libcrexec/README.md line 19:

> 17: 
> 18: There is one line per tag created through the `crlib_image_constraints_t` interface, using either the `label:` or `bitmap:` prefix, followed by the tag name and `=`-separated value. In case of bitmap this is encoded as a string of two hexadecimal characters per byte (`<higher-4-bits><lower-4-bits`) in memory order. The string in the example is recorded when JVM runs with:
> 19: 

IIRC, for constraints we forbid `=` and `\n` in both names and values

src/java.base/share/native/libcrexec/README.md line 37:

> 35: ### User Data
> 36: 
> 37: While currently not utilized by the JVM, C/R Exec can store custom data in the checkpoint directory. The filename uses the name passed to `crlib_user_data_t`, and the data is encoded as a string of two hexadecimal characters per byte (`<higher-4-bits><lower-4-bits`) in memory order. It is up to JVM to ensure that there would be no conflict with name used by another extension or engine implementation.

Suggestion:

While currently not utilized by the JVM, C/R Exec can store custom data in the checkpoint directory. The filename uses the name passed to `crlib_user_data_t`, and the data is encoded as a string of two hexadecimal characters per byte (`<higher-4-bits><lower-4-bits>`) in memory order. It is up to JVM to ensure that there would be no conflict with name used by another extension or engine implementation.

src/java.base/share/native/libcrexec/README.md line 38:

> 36: 
> 37: While currently not utilized by the JVM, C/R Exec can store custom data in the checkpoint directory. The filename uses the name passed to `crlib_user_data_t`, and the data is encoded as a string of two hexadecimal characters per byte (`<higher-4-bits><lower-4-bits`) in memory order. It is up to JVM to ensure that there would be no conflict with name used by another extension or engine implementation.
> 38: 

I believe this is an extra newline, i.e. there are two newlines at the EOF

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2455018904
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2455046240
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2455049197
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2455051933