The return type of os::physical_memory was changed from the 64-bit julong to the platform dependent sized size_t (32 bits on our 32-bit architectures and 64 bits on our 64-bit architectures) in JDK-8357086. The anticipation was that there is a 1-to-1 mapping between the addressable range of memory and the physical amount of memory and that 32 bits where enough for 32-bit JVMs.

This is not true when a 32-bit JVM is run in a 64-bit OS.

It's not even true in all 32-bit OSes. For example, x86 has the PAE (Physical Address Extension), which allows for a larger amount of physical memory. Note though that we removed the 32-bit support in JDK 25, so the PAE is of no concern here. However, Arm seems to have its own version of that called LPAE.

This is the part that changed:
```
- _physical_memory = (julong)sysconf(_SC_PHYS_PAGES) * (julong)sysconf(_SC_PAGESIZE);
+ _physical_memory = static_cast<size_t>(sysconf(_SC_PHYS_PAGES)) * static_cast<size_t>(sysconf(_SC_PAGESIZE));
```

Note how the man pages caution about the overflow:
```
        - _SC_PHYS_PAGES
              The number of pages of physical memory. Note that it is
              possible for the product of this value and the value of
              _SC_PAGESIZE to overflow.
```

The main (but not only) usage of os::physical_memory is to set up the heap size. Note that in JDK 17 we already broke 32-bit JVMs here when JDK-8257970 was integrated. After that change we convert the derivative of os::physical_memory into a size_t via limit_heap_by_allocatable_memory.