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

[Aleksey Shipilev]

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.

So it looks like JDK-8357086 made the assumption that `size_t` is enough to represent system memory sizes on 32-bit systems. Which is demonstrably not true, since 32-bit PAE systems are a thing :) Yes, if we don't want to go back to `julong`, memory sizes should be in `uint64_t`.

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

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