RFR: 8365606: Container code should not be using jlong/julong [v2]

[Severin Gehwolf]

On Fri, 24 Oct 2025 11:22:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8365606-jlong-julong-refactor
>>  - Fix print_container_info output
>>  - whitespace clean-ups and other small fixes
>>  - Fix log format in container macro and scanf format
>>  - Fix duplicate include in osContainer_linux
>>  - 8365606: Container code should not be using jlong/julong
>
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp line 80:
> 
>> 78:     return false;                                                                     \
>> 79:   }                                                                                   \
>> 80:   log_trace(os, container)(log_string " is: " UINT64_FORMAT, retval);                 \
> 
> Here and in other places: don't use raw UINT64_FORMAT; use `PHYS_MEM_TYPE_FORMAT` instead.

This is intentional since the processor_count API doesn't use `physical_memory_size_type` (as it doesn't make sense in this context). See, for example, `CgroupV2CpuController::cpu_period()`. The common denominator is `uint64_t`. This is a bit awkward, but I don't know a better way to deal with this. The reading functions are shared, most of the API is used for memory value reading (but not exclusively, exceptions are `pid`, `cpu`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27743#discussion_r2510577587