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

[Severin Gehwolf]

On Mon, 27 Oct 2025 14:19:19 GMT, Thomas Fitzsimmons <fitzsim 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.cpp line 653:
> 
>> 651:   cpu_count = os::Linux::active_processor_count();
>> 652:   if (!CgroupUtil::processor_count(contrl->controller(), cpu_count, result)) {
>> 653:     return false;
> 
> `value` will be returned unchanged from its passed-in value here.  I wonder if it would be safer to explicitly set it to `0` when returning `false`.  Also, could `value` be given an unsigned type, like `uint64_t`?

The general contract in those functions is that the result reference is unchanged when `false` is being returned. So this is intentional.

> Also, could value be given an unsigned type, like uint64_t

I've tried to keep the `int` based processor_count API as is. Not sure if we need an unsigned type here. We could if that's the consensus, but then it would make the patch even larger.

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

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