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

[Severin Gehwolf]

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