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

[Baesken, Matthias]

Hi Mikhailo , thanks for the review .

Will push it as XS  tomorrow  in case no complains show up in the meantime .

Best regards, Matthias


> -----Original Message-----
> From: Mikhailo Seledtsov <mikhailo.seledtsov at oracle.com>
> Sent: Dienstag, 27. August 2019 19:20
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR: [XS] 8229284: [TESTBUG]
> jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for -
> memory:getMemoryUsage
> 
> 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(MetricsTest
> er.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(NativeMet
> hodAccessorImpl.java:62)
> > at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega
> tingMethodAccessorImpl.java:43)
> > at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> > at
> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp
> er.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/
> >
> >