Overhead of -XX:+UseContainerSupport

[David Holmes]

See also the related discussion in:

https://bugs.openjdk.java.net/browse/JDK-8227006

In general we can't cache anything because it is all dynamic and might 
change. :(

David

On 2/09/2019 10:00 pm, Severin Gehwolf wrote:
> 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
>