RFR: 8292541: [Metrics] Reported memory limit may exceed physical machine memory [v2]

[Jonathan Dowland]

On Thu, 25 Aug 2022 10:09:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   avoid calling subsystem.getMemoryLimit twice
>
> src/java.base/linux/native/libjava/CgroupMetrics.c line 41:
> 
>> 39: Java_jdk_internal_platform_CgroupMetrics_getTotalMemorySize0
>> 40:   (JNIEnv *env, jclass ignored)
>> 41: {
> 
> Why not do it the same way hotspot does? 
> 
>   sysinfo(&si);
>   avail_mem = (julong)si.freeram * si.mem_unit;
> 
> if for some weird reason the APIs return different numbers, at least we use the same numbers in JDK and VM.

I don't have a strong preference for `sysconf` over `sysinfo`: The former avoids an explicit local variable but I guess that doesn't really matter. I take your point about possible divergent values from hotspot. Unfortunately there's a third example, `Java_com_sun_management_internal_OperatingSystemImpl_getFreeMemorySize0` in [src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c](https://github.com/openjdk/jdk/blob/master/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#L249) which is where I took the `sysconf` approach from.

(I don't think it is practical for the code I've changed here, `CgroupMetrics`, to re-use the existing (currently private) native method `getTotalMemorySize0` in `OperatingSystemImpl` due to circular dependency issues).

With respect to consistency with hotspot: out of scope for these two bugs, perhaps hotspot could export the data structures it populates from cgroups for internal (to the jdk) consumption, and we could avoid re-parsing the cgroup structures in Java code entirely. That would guarantee consistency and mean that the consumers benefit from e.g. the caching that the hotspot code has and this lacks. This might make a good RFE?

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

PR: https://git.openjdk.org/jdk/pull/10017