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

[Thomas Stuefe]

On Wed, 17 Sep 2025 08:42:11 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 checking if the product (represented as `uint64_t`) exceeds the maximum value representable by `size_t`, and, if so `std::numeric_limits<size_t>::max()` is returned as physical memory. If there is no overflow detected, the product of _SC_PHYS_PAGES  and _SC_PAGESIZE  is returned. 
> 
> Note that this change does not roll back to the old behavior (pre https://bugs.openjdk.org/browse/JDK-8357086). We keep consistency among memory functions return types.
> 
> Tested in tiers 1 - 3.

Do we really want to do this? This feels like regressing. 32-bit is on the way out.

Why not just cap the returned value to SIZE_MAX/4G in this case, since for all practical matters the JVM will not be able to handle more memory? Or do we use LPAE anywhere? Why cater to such an odd corner case?

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

PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3303070087