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

[Thomas Stuefe]

On Thu, 25 Aug 2022 12:41:31 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

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

Okay, lets leave it this way. One would hope the results are identical.

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

Possibly. Personally, I would not broaden the JVM interface for that, but I have not looked deeply enough into the java implementation to weigh in.

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

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