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

[Severin Gehwolf]

On Wed, 2019-08-28 at 09:23 -0400, Bob Vandette wrote:
> Should you continue waiting in the loop until BOTH the new usage and max usage exceed their
> initial values?

Is it ever possible for the high water mark sequence,
metrics.getMemoryMaxUsage(), to ever decrease? I'd think not, so my
reasoning would be the call after the loop (newMemoryMaxUsage) must be
>= memoryMaxUsage. Then the failure condition of 'newMemoryMaxUsage <
memoryMaxUsage' must not be satisfied unless it's a bug, right?

Thanks,
Severin

> Bob.
> 
> 
> > On Aug 28, 2019, at 8:39 AM, Baesken, Matthias <
> > matthias.baesken at sap.com> wrote:
> > 
> > Hi Severin, I changed  the  fail() - calls   and
> > the  newMemoryMaxUsage handling.
> > New webrev :
> > 
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.5/
> > 
> > 
> > Best regards, Matthias
> > 
> > 
> > > On Thu, 2019-08-15 at 16:08 +0000, Baesken, Matthias wrote:
> > > > https://bugs.openjdk.java.net/browse/JDK-8229284
> > > > 
> > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.3/
> > > 
> > > Hmm, unrelated to this bug, but still an issue:
> > > 
> > > It appears the failure message is bogus when the test fails. It
> > > should
> > > be:
> > > 
> > > java.lang.RuntimeException: Test failed for -
> > > memory:getMemoryUsage,
> > > expected [56200986624], got [56019386368]
> > > 
> > > I.e. the old/new values need to be swapped here:
> > > 
> > > 597             fail(SubSystem.MEMORY, "getMemoryUsage",
> > > newMemoryUsage, memoryUsage);
> > > 
> > > Same for the getMemoryMaxUsage() fail:
> > > 
> > > 592             fail(SubSystem.MEMORY, "getMemoryMaxUsage",
> > > newMemoryMaxUsage,
> > > 593                     memoryMaxUsage);
> > > 
> > > As to the bug. It suggests the memoryUsage code causes problems,
> > > not
> > > memoryMaxUsage.
> > > 
> > > 587         // allocate memory in a loop and check more than once
> > > for new
> > > values
> > > 588         // otherwise we might see seldom the effect of
> > > decreasing new
> > > memory values
> > > 589         // e.g. because the system could free up memory
> > > 590         byte[][] bytes = new byte[32][];
> > > 591         for (int i = 0; i < 32; i++) {
> > > 592             bytes[i] = new byte[8*1024*1024];
> > > 593             newMemoryMaxUsage = metrics.getMemoryMaxUsage();
> > > 594             newMemoryUsage = metrics.getMemoryUsage();
> > > 595             if (newMemoryMaxUsage > memoryMaxUsage &&
> > > newMemoryUsage > memoryUsage) {
> > > 596                 break;
> > > 597             }
> > > 
> > > Do we really need to call metrics.getMemoryMaxUsage() in that
> > > loop? I'd
> > > expect for the following code to work more reliably as the max
> > > usage is
> > > supposed to capture the high water mark. If memoryMaxUsage ever
> > > decreases, it's a bug in the cgroups accounting system right?
> > > 
> > > byte[][] bytes = new byte[32][];
> > > for (int i = 0; i < 32; i++) {
> > >    bytes[i] = new byte[8*1024*1024];
> > >    newMemoryUsage = metrics.getMemoryUsage();
> > >    if (newMemoryUsage > memoryUsage) {
> > >        break;
> > >    }
> > > }
> > > newMemoryMaxUsage = metrics.getMemoryMaxUsage();
> > > 
> > > // assert things
> > > 
> > > Perhaps even assert prior the loop:
> > > 
> > > if (memoryMaxUsage < memoryUsage) {
> > >    throw new RuntimeException("cgroup accounting bug?");
> > > }
> > > 
> > > Thanks,
> > > Severin