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

[Yasumasa Suenaga]

On Wed, 7 Apr 2021 07:23:08 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>>> 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);

I pushed new commit to use resource controller name to show both UL and VM.info.
In UL, resource controller name ("cgroupsv1" or "cgroupsv2") will be added to UL message, but the log is tagged os+container, so the user aware it might relates to the container, and they can know it says about cgroups.

It has tested with test/hotspot/jtreg/containers jtreg tests on Linux x64.

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

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