On Thu, 25 Aug 2022 12:41:31 GMT, Jonathan Dowland <jdowl...@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
