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

[Stefan Karlsson]

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.

I really would have preferred if we could have used size_t for these, but as long as we are keeping 32-bit JVMs on life support I think we need to change this to use uint64_t.

I also considered the same approach that Anton proposes here, but I think it breaks code like this:

bool os::used_memory(size_t& value) {
...
  size_t avail_mem = 0;
  // Return value ignored - defaulting to 0 on failure.
  (void)os::available_memory(avail_mem);
  size_t phys_mem = os::physical_memory();
  value = phys_mem - avail_mem;
  return true;
}

The `os::available_memory` function needs to work the same way as `os::physical_memory` and if if both cap at 4 GB we will end up returning the wrong amount of used memory. We'll probably even return 0 used memory if the machine has a lot of memory.

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

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