On Thu, 25 Aug 2022 10:09:32 GMT, Thomas Stuefe <stu...@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
