Overhead of -XX:+UseContainerSupport

[Severin Gehwolf]

Hi,

Adding Bob Vandette. More below.

On Sun, 2019-09-01 at 18:55 +0200, Florian Weimer wrote:
> On OpenJDK 12, running
> 
>   jshell -J-Xlog:container*=trace 
> 
> suggests that the container memory amount is not cached at all.  (I
> use jshell as a non-trivial example program, the issue appears to
> affect everything.)
> 
> strace also shows lots of openat calls for paths like this one:
> 
> /sys/fs/cgroup/memory/user.slice/user-1000.slice/session-1.scope/memory.limit_in_bytes
> 
> All this goes away with -XX:-UseContainerSupport, but the default is
> enabled.
> 
> These calls appear to be triggered by the Hotspot compiler (they go
> away with -Xint), so in a sense this is just a warmup effect.  But I
> do wonder if there is a better way of doing this.

This seems to affect OpenJDK 11.0.4 as well (and probably OpenJDK 8u,
but jshell is not available in 8). Changing the jshell command line to:

$ jshell -J-Xlog:os=trace

shows many "available memory: XXXX" calls, which directly translates to
os::available_memory() calls, which go through the container detection
code first and then uses sysinfo() on Linux.

Implementation of this changed with:
https://bugs.openjdk.java.net/browse/JDK-8146115

Without UseContainerSupport the container memory limit code does not
run and only sysinfo() calls are being done.

Bob what was the rationale for not caching container memory limits (if
any)?

In practice, when using docker or podman, the container memory limit
doesn't really change at runtime, does it? In the container world
restarts are quite frequent. In theory, the cgroup values might change
at runtime - if written to by an admin, for example - but I wonder how
frequent a use-case that would be. Thoughts?

Thanks,
Severin