RFR [XS]: 8244500: jtreg test error in test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java

[Severin Gehwolf]

Hi Matthias,

Thanks for running this to get better diagnostics!

On Thu, 2020-06-04 at 14:11 +0000, Baesken, Matthias wrote:
> HI Severin, with your new patch I run into :
> 
> java.lang.RuntimeException: 'OperatingSystemMXBean.getTotalSwapSpaceSize: [1-9][0-9]+' missing from stdout/stderr 
> 
> 	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:189)
> 	at TestMemoryAwareness.testOperatingSystemMXBeanAwareness(TestMemoryAwareness.java:165)
> 	at TestMemoryAwareness.main(TestMemoryAwareness.java:66)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> 	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.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
> 	at java.base/java.lang.Thread.run(Thread.java:832)
> 
> Did you really mean in line 165 of  TestMemoryAwareness.java
>  out.shouldContain("OperatingSystemMXBean.getTotalSwapSpaceSize: [1-9][0-9]+");
> ?
> When I fix it  (to shouldMatch , this was probably meant by you)

Yes, that's what I meant.

> I get the next error -
> java.lang.RuntimeException: 'Metrics.getMemoryLimit() == -1' missing from stdout/stderr
> 
> I have
> 
> Metrics.getMemoryAndSwapLimit() == -1
> Metrics.getMemoryLimit() == 104857600
> Metrics.getMemoryAndSwapUsage() == -1
> Metrics.getMemoryUsage() == 30670848

OK. I've added this info to the bug and some more bits and pieces. I
believe there isn't much we can do but to bail out and let the test
pass... It would be good to only pass the test that way on a system
without kernel support for swap limits. Here would be my suggestion
(hopefully this one isn't too restrictive again):
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244500/03/webrev/

If we changed OperatingSystemMXbean as suggested by Bob to return 0 in
this case for getTotalSwapSpaceSize(), it would be incorrect for the
case as described in the bug (--memory-swap=-1). That would actually be
unlimited swap.

> Could we omit the 
> 
> out.shouldContain("Metrics.getMemoryLimit() == -1");
> 
> check ?

We could. I'd rather be more specific and use expectedMemoryLimit
instead, though. That's what the webrev above does. Feel free to change
it in a way so that it passes on the affected system as I'd have to
keep guessing :)

In conclusion: This seems a test bug to me.

Thanks,
Severin