RFR: 8236617: jtreg test containers/docker/TestMemoryAwareness.java fails after 8226575

[Bob Vandette]

Matthias,

I really don’t like testing for some Docker message that could possibly change or go away in the future.
There may be other reasons that the getTotalSwapSpaceSize function will fail and return 0.

The real problem here is that the OperatingSystemMXBean.getTotalSwapSpaceSize is returning a 
negative value when there is no swap available.  

I’d prefer that we fix this problem by correcting the getTotalSwapSpaceSize function to properly return 0
under these conditions and allow 0 to be a valid expected result in the test.

 if (limit >= 0 && memLimit >= 0) {
   return (limit < memLimit) ? 0 : limit - memLimit;
 }

Note:  My suggestion assumes that there is no swap available when the kernel swap limit capability is not enabled.
           I have not verified this.  The message does claim that this is the case "Memory limited without swap”.

Bob.


> On Jan 2, 2020, at 8:26 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hello, please review this small adjustment to  jtreg test  containers/docker/TestMemoryAwareness.java .
> 
> After change   "8226575: OperatingSystemMXBean should be made container aware"    has been pushed,
> we observe failures on linux s390x / ppc64le in the docker related jtreg tests  .
> 
> 
> The test runs into  the following error :
> java.lang.RuntimeException: 'OperatingSystemMXBean.getTotalSwapSpaceSize: 52428800' missing from stdout/stderr
> 
> at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:187)
> at TestMemoryAwareness.testOperatingSystemMXBeanAwareness(TestMemoryAwareness.java:154)
> at TestMemoryAwareness.main(TestMemoryAwareness.java:65)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:832)
> 
> 
> The reason is that the value found is instead     OperatingSystemMXBean.getTotalSwapSpaceSize: -104857600    .
> When looking into the getTotalSwapSpaceSize() function, we get values of 0 for "limit" and 104857600 for "memLimit" :
> 
> 57 long limit = containerMetrics.getMemoryAndSwapLimit();
> ....
> 62 long memLimit = containerMetrics.getMemoryLimit();
> 63 if (limit >= 0 && memLimit >= 0) {
> 64 return limit - memLimit;
> 65 }
> 
> That explains the value "-104857600" . We see messages    "Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap" , this most likely
> causes the unexpected limit == 0  value  .
> 
> 
> Bug/webrev :
> 
> https://bugs.openjdk.java.net/browse/JDK-8236617
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8236617.0/
> 
> 
> Thanks, Matthias