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

[Thomas Stuefe]

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

We could also just bypass the compiler thread creation question for now. Let the compiler continue to use the old metric when calculating its thread count, but let all other users of os::available_memory() the new one.

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

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