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

[Aleksey Shipilev]

On Wed, 17 Sep 2025 13:41:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

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

Conceptually, the machine data model width (`size_t`) does not put a limit on system memory size. So, switching from `julong` to `size_t` in JDK-8357086 _is_ the regression from that concept. `size_t` is simply a too narrow type to use here, even if it happens to work on 64-bits. We can assume that 64-bit would be enough to cover all machines, so `uint64_t` would work.

> 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? 

AFAICS, this data is fed to various management beans reporting the system memory size, so capping at 4G contradicts their intended behavior, if not their spec?

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

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