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

Baesken, Matthias matthias.baesken at sap.com
Wed Aug 28 12:39:47 UTC 2019


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



More information about the hotspot-dev mailing list