RFR: 8264482: container info misleads on non-container environment [v2]

[Yasumasa Suenaga]

On Tue, 6 Apr 2021 12:06:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> @YaSuenag Unfortunately that's the status quo, yes. On a plain linux system without cgroup limits for the java process, but with the cgroup subsystem mounted, it'll report some cgroup (container) metrics (same as the host values, though). What I'm unsure about is whether or not this is a problem worth fixing. The main idea is abstraction from cgroups in the container code. It does say `container (cgroup) information` in the heading.
>
>> What I'm unsure about is whether or not this is a problem worth fixing.
> 
> I think fundamental solutions will be implemented in JDK-8261242, but It seems to be a difficult task.
> 
>> The main idea is abstraction from cgroups in the container code. It does say `container (cgroup) information` in the heading.
> 
> I know that, but "container_type" label is in hs_err / VM.info log. In addition, UL reports some metrics as "container" in spite of cgroups.
> If it takes a long time to fix JDK-8261242, I want to fix log messages for cgroups for next LTS release at least. "container" messages may make the customer do extra work to collect / analyzer their system.

> Then can we compromise and just say "container/cgroup" everywhere?

How about following change?
It is easy to add new resource controller other than cgroups in future.

// get_resource_container_name() will return "cgroups" or "cgroupsV2"
const char *resource_controller_name = OSContainer::get_resource_container_name();

log_debug(os, container)("%s memory limit %s: " JLONG_FORMAT ", using host value",
                       resource_controller_name,
                       mem_limit == OSCONTAINER_ERROR ? "failed" : "unlimited", mem_limit);

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

PR: https://git.openjdk.java.net/jdk/pull/3280