RFR: 8305770: os::Linux::available_memory() should refer MemAvailable in /proc/meminfo

[Yasumasa Suenaga]

On Sat, 8 Apr 2023 02:24:44 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `os::Linux::available_memory()` returns available memory from cgroups or sysinfo(2). In case of the process which run on out of container, that value is based on `freeram` from sysinfo(2).
> 
> `freeram` is equivalent to `MemFree` in `/proc/meminfo` [1]. However it means just a free RAM. We should use `MemAvailable` when we want to know how much memory is available for the process [2]. `MemAvailable` is available in modern Linux kernel, and it has been backported some older kernels (e.g. RHEL). In `sar` from sysstat, it refers that value and shows it as `kbavail` [3].
> 
> AFAIK PhysicalMemory event in JFR depends on `os::Linux::available_memory()`, and it is used in automated analysis in JMC. So the JFR/JMC user could misunderstand physical memory was exhausted even if the memory was available enough.
> 
> [1] https://github.com/torvalds/linux/blob/c9c3395d5e3dcc6daee66c6908354d47bf98cb0c/fs/proc/meminfo.c#L59
> [2] https://docs.kernel.org/filesystems/proc.html?highlight=memavailable
> [3] https://github.com/sysstat/sysstat/blob/ac1df71ca252c158e8d418ded93e5ed52f5e8765/rd_stats.c#L325-L328

There appears to be no consistency in `os::available_memory()`. I think there are big difference between Linux, BSD, Windows. What is expected in this function?

* Linux
    * cgroups - memory limit - memory usage
    * sysinfo(2) - equivalent to MemFree in /proc/meminfo
* Windows
    * GlobalMemoryStatusEx() - I guess it is equivalent to MemAvailable in Linux
* AIX
    * libo4::get_memory_info()
    * perfstat_memory_total()
* BSD
    * 1/4 of physical memory
* macOS
    * host_statistics64()

In compiler thread, the policy may be different in each platforms.

If we add `os::free_memory()`, we have to implement it into os_linux, os_aix, os_bsd, os_windows. Wouldn't the impact be significant?

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

PR Comment: https://git.openjdk.org/jdk/pull/13398#issuecomment-1527463178