RFC: Backport cgroups v2 to 8u

[Andrew Hughes]

On 14:46 Wed 21 Sep     , Severin Gehwolf wrote:
> Hi,
> 
> We, Red Hat, think that getting cgroups v2 support backported to JDK
> 8u will be needed long-term. Systems which use cgroups v2 by default
> become more an more widely used. For example Red Hat Enterprise Linux
> 9[1] will have it turned on by default. Recent Fedora and Ubuntu
> distributions have it on by default. Similarly, container technology
> such as Docker and Kubernetes support cgroups v2 as well.
> 
> With more and more systems defaulting to cgroups v2, the likelihood of
> users deploying legacy JDKs such as JDK 8u on a cgroups v2 system
> increases. With container technology it's possible, to deploy an
> application based on, say, UBI 8 onto a cgroups v2 host system, like
> Red Hat Enterprise Linux 9. As cgroups is a kernel feature, the host
> kernel (and cgroup configuration) is the one that counts as far as
> application runtime is concerned.
> 
> The risk of NOT backporting those patches is that the JVM would wrongly
> detect resource limits in such a scenario. Even though,
> -XX:+UseContainerSupport is on by default in 8u, container detection
> code would just give up early and would use the host systems' resource
> limits instead. That gets us back to pre-JDK-8146115[2] behaviour of
> the JDK when running on such systems. I.e. random OOM kills and other
> strange behaviour. IMHO, that would be very bad.
>

So my understanding of this is that it's already a problem, as RHEL 9
is available and includes OpenJDK 8u. Other distributions no doubt
keep 8u packages around as well.

> Cgroups v2 support has been available in the JDK since version 15 and
> up and has recently been backported to 11.0.16. I believe, most bugs
> have been shaken out in due course. Support code has been pretty stable
> over the last couple of major JDK releases. The code is Linux-only and
> is pretty self-contained. It is our belief that the risks of
> introducing those patches to 8u is manageable. At the very least, we
> think NOT doing the backport is riskier.
>

I think it is definitely less risky than JMC or TLSv1.3, though both
were backported earlier in 8u's lifecycle.

> While JDK 8u is in maintenance mode, this would be one of the few
> exceptional enhancements needed to adapt to new computing environments.
> 
> Therefore, we propose to (roughly) backport the following patch-set
> from JDK 15+:
> 
> Cgroups v2: Container awareness
> https://bugs.openjdk.java.net/browse/JDK-8230305
> 
> Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy
> https://bugs.openjdk.java.net/browse/JDK-8231111
> 
> 8230305 causes slowdebug build failure
> https://bugs.openjdk.java.net/browse/JDK-8237479
> 
> [cgroups v2] Soft memory limit incorrectly using memory.high
> https://bugs.openjdk.java.net/browse/JDK-8253714
> 
> Cgroups: Incorrect detection logic on old systems in hotspot
> https://bugs.openjdk.java.net/browse/JDK-8239785
> 
> Cgroups: Incorrect detection logic on some systems
> https://bugs.openjdk.java.net/browse/JDK-8239559
> 
> jtreg test error in test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> https://bugs.openjdk.java.net/browse/JDK-8244500
> 
> containers/cgroup/PlainRead.java fails on Ubuntu 21.10
> https://bugs.openjdk.java.net/browse/JDK-8278951
> 
> [cgroups v2] Account for the fact that swap accounting is disabled on some systems
> https://bugs.openjdk.java.net/browse/JDK-8253797
> 
> Cgroups: Incorrect detection logic on some systems (still reproducible)
> https://bugs.openjdk.java.net/browse/JDK-8245543
> 
> [Metrics] Enhance parsing of cgroup interface files for version detection
> https://bugs.openjdk.java.net/browse/JDK-8254001
> 
> HotSpot Not Identifying it is Running in a Container
> https://bugs.openjdk.java.net/browse/JDK-8252359
> 
> Cgroup: 'stomping of _mount_path' crash if manually mounted cpusets exist
> https://bugs.openjdk.java.net/browse/JDK-8253435
> 
> [TESTBUG] Increase coverage of the cgroups detection code
> https://bugs.openjdk.java.net/browse/JDK-8253939
> 
> Thoughts? Objections?
>

Do you plan to target these all to one particular release, or just
when they happen to be integrated?

I would ask that we hold off integrating until after the upcoming CPU,
as I know people like myself, who will at least want to look over such
major changes, will be very busy with security updates for the next
couple of weeks.  Late October and early November, however, would be a
great time to get the bulk of this integrated.

> Thanks,
> Severin
> 

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20220928/a3d545f9/signature-0001.asc>