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