RFR: [XS] 8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage

[Mikhailo Seledtsov]

Looks reasonable to me,
Thank you,
Misha

On 8/15/19, 9:08 AM, Baesken, Matthias wrote:
> Hello, please review this small test  adjustment .
>
> We sometimes see failures in the jtreg test jdk/internal/platform/cgroup/TestCgroupMetrics.java .
> Failures look like :
>
> java.lang.RuntimeException: Test failed for - memory:getMemoryUsage, expected [56019386368], got [56200986624]
> at jdk.test.lib.containers.cgroup.MetricsTester.fail(MetricsTester.java:207)
> at jdk.test.lib.containers.cgroup.MetricsTester.testMemoryUsage(MetricsTester.java:597)
> at TestCgroupMetrics.main(TestCgroupMetrics.java:53)
> 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:567)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:830)
>
>
> Looking at the coding in MetricsTester.java we expect that "memory.usage_in_bytes" gets larger after  one  additional allocation of 64 M.
> However this is sometimes not the case.
>
> Reason might be that a GC kicked in and freed space; or for some reasons OS pages were freed.
>
> So I make the test   more robust and do some allocations in a loop,   breaking out of the loop  after new values got larger than initial ones .
>
>
> Thanks, Matthias
>
> Bug/webrev :
>
> https://bugs.openjdk.java.net/browse/JDK-8229284
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.3/
>
>