[crac] RFR: 8371337: [CRaC] Fastdebug build fails when calling OperatingSystemMxBean.getProcessCpuLoad after restore

[Timofei Pushkin]

On Wed, 5 Nov 2025 12:21:23 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> A JVM that executed OperatingSystemImpl.getProcessCpuLoad()  before checkpoint can fail with assertion failure after restore with:
> 
> java: /home/rvansa/work/zulu/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c:291: get_cpuload_internal: Assertion `pticks->usedKernel >= tmp.usedKernel' failed.
> 
> This is an assertion failure, therefore failing only in debug builds, and providing probably a non-sense value in release builds. We should remove the assertion and return a negative value (documented as value for ‘unavailable’) if this is detected.

src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c line 290:

> 288:         // After restoring with CRaC the new process can appear 'younger'
> 289:         // than last value in counters - we will return -1 (unavailable).
> 290:         if (!failed && pticks->usedKernel >= tmp.usedKernel) {

I haven't read the precise definitions of `used`, `usedKernel`, `total`, is checking only `usedKernel` enough to guarantee the comparison is also valid for the other two values? Shouldn't we check both `used` and `usedKernel` (assuming `total` is exactly their sum, which may not be the case) in case only one of them has gone backwards?

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

PR Review Comment: https://git.openjdk.org/crac/pull/274#discussion_r2517357741