Downport 8217338: [Containers] Improve systemd slice memory limit support

[Langer, Christoph]

Hi,

I just took a glance at the fix and think there is no concern which would necessitate a backout. Especially not at this stage of the April Update release process.

We should definitely also take in JDK-8232207 and JDK-8227006. The former will be done anyway since it's already part of Oracle 11.0.7.

So I'm approving this now. If anybody has objections, don't hesitate to speak up.

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Mittwoch, 8. Januar 2020 15:55
> To: Severin Gehwolf <sgehwolf at redhat.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] RE: Downport 8217338: [Containers] Improve systemd
> slice memory limit support
> 
> Hi Severin,
> 
> > ... being pro-active about it.
> I guess I was a bit too pro-active :)
> 
> But yes, I flagged jdk11u-fix-request. I think this is the
> best to do.
> 
> Best regards,
>   Goetz.
> 
> 
> > -----Original Message-----
> > From: Severin Gehwolf <sgehwolf at redhat.com>
> > Sent: Mittwoch, 8. Januar 2020 15:43
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > Cc: jdk-updates-dev at openjdk.java.net
> > Subject: Re: Downport 8217338: [Containers] Improve systemd slice
> memory
> > limit support
> >
> > Hi Goetz!
> >
> > On Wed, 2020-01-08 at 10:19 +0000, Lindenmaier, Goetz wrote:
> > > Hi Severin, everybody,
> > >
> > > I wanted to follow your plan and let you do this downport.
> > > But it was in one of my queues in between of other changes
> > > that were approved and which I can push.
> > > Now I accidentally pushed this change along with the others,
> > > sorry!
> >
> > I see. Thanks for the heads-up and being pro-active about it.
> >
> > > I ran the change through our testing and it's all green.
> > > But I did not request downport, so it was not approved (yet).
> > > Also I thought it needs some discussion as Andrew Haley
> > > had questioned it in a comment:
> > > https://bugs.openjdk.java.net/browse/JDK-8217338
> > > It brings some changes in internal classes in java.base.
> >
> > Those changes were all in jdk.internal.platform related classes.
> > Metrics.java is also Linux-only. While it changes the binary
> > compatibility, I'm not sure this is a concern in practice.
> >
> > > What should I do? Should I back it out, or should
> > > I request downport and only back it out in case downport
> > > is rejected?
> >
> > I'd say request downport and if approved keep it in. It was a clean
> > backport wasn't it? Also, this is in JDK 13 and I haven't heard of
> > problems.
> >
> > My concern originally was JDK-8227006 (and friends). With JDK-8232207
> > the idea of caching for some period of time came up and paved the way
> > for a fix for JDK-8227006.
> >
> > Since the plan is to downport this *and* JDK-8232207 it should be fine.
> > JDK-8232207 fixes the perf regression in hotspot runtime related to
> > cgroups.
> >
> > > Me personally am in favour of bringing the cgroup improvements
> > > to 11. I think it's an important thing for Java to support.
> >
> > +1
> >
> > There are more changes in the pipeline, fwiw. Cgroups v2 support being
> > one.
> >
> > Thanks,
> > Severin