RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v9]

[Thomas Stuefe]

On Fri, 19 Sep 2025 08:01:44 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
>> 
>> The issue is addressed by changing the output type of all related functions to `uint64_t`.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367485: Alignment of vars in os_windows.cpp

I am okay with this, albeit hesitatingly.

I think this worsens the code quality and is prone to bitrot. `size_t` carries a meaning: it is generally understood to be a measurement for a memory size, even though in hotspot it often gets misused for counters. That was the underlying reason for the original size_t change.

We now have a distinction between reported memory size and size of memory the process can address, and some APIs return the former now whereas the bulk of APIs works with the latter. The distinction is obfuscated by using a plain `uint64_t`, it could be made more explicit (and later cleanup after 32-bit has gone would be easier) with something like `typedef uint64_t physical_memory_size_t`.

But other reviewers are okay with this and I don't want to hold up this change. In any case, thanks for taking care of this  @toxaart - dealing with opinion-laden issues like this is never fun.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27335#pullrequestreview-3248812961