RFR: 8300658: memory_and_swap_limit() reporting wrong values on systems with swapaccount=0 [v4]
Severin Gehwolf
sgehwolf at openjdk.org
Fri Feb 17 14:06:53 UTC 2023
On Thu, 16 Feb 2023 19:43:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:
> 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.
Done in the update. We still need to distinguish between `OSCONTAINER_ERROR` returns and `-1` returns though. The former, resets it to the memory limit. The latter returns `-1`. At the same time, I've restructured how `swappiness` values are handled. IMO this makes it easier to read.
> 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 [#12166 (comment)](https://github.com/openjdk/jdk/pull/12166#discussion_r1106387099) :-)
Yes, we need to refactor the code. In particular, I'd like to get rid of the `GET_CONTAINER_INFO` macros as they're a pain to work with. I've filed https://bugs.openjdk.org/browse/JDK-8302744 to get this done.
-------------
PR: https://git.openjdk.org/jdk/pull/12262
More information about the hotspot-runtime-dev
mailing list