RFR: 8300658: memory_and_swap_limit() reporting wrong values on systems with swapaccount=0 [v4]

[Ioi Lam]

On Thu, 16 Feb 2023 17:23:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change which brings the hotspot code up to date with how the Java metrics behave. On a system where swap accounting is disabled `VM.info` jcmd - for example - no longer reports an unsupported metric, but the memory limit instead as that is actually what is being in place.
>> 
>> I had to update the `TestMemoryWithCgroupV1.java` test as it skipped the swappiness testing based on the now gone output.
>> 
>> Testing:
>> - [x] Linux container tests on cg1 and cg2 with and without swap accounting.
>> - [x] New regression test fails on unpatched systems with `swapaccount=0` kernel option. Passes after.
>> - [x] GHA (linux tier1 failure is unrelated).
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use OSCONTAINER_ERROR constant instead

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 104:

> 102:                      "Memory and Swap Limit is: ", JULONG_FORMAT, JULONG_FORMAT, memswlimit);
> 103:   return memswlimit;
> 104: }

I think the API (and behavior) should following existing functions like:


jlong CgroupV1Subsystem::read_memory_limit_in_bytes()

Which returns:

- -2 when there was an error in determining the limit
-  -1 when there's no limit, or if the limit is larger than a reasonable physical maximum
- otherwise a non-negative number

That way, you won't need to do the awkward casting in the callers to check for OSCONTAINER_ERROR.

Since this is a recurring pattern, maybe this will be a good time to introduce a utility function for reading and capping the limit, as I suggested in https://github.com/openjdk/jdk/pull/12166#discussion_r1106387099 :-)

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

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