RFC: Backport cgroups v2 to 8u

[Severin Gehwolf]

On Wed, 2022-09-28 at 17:41 +0100, Andrew Hughes wrote:
> 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.

Yes.

> > 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.

OK.

> > 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?

It'll depend on when PRs for them become available. We cannot integrate
them as we go along, as most of them are interrelated or fix bugs in
earlier versions. So the plan would be to integrate (the set of) them
for the January 2023 or April 2023 release whichever we can make.

> 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.

OK. It'll probably be later, but who knows :)

Thanks,
Severin