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

Bob Vandette bob.vandette at oracle.com
Wed Aug 28 13:49:03 UTC 2019



> On Aug 28, 2019, at 9:41 AM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> 
> 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?

That’s true but what the test is trying to do is to cause memory to be allocated and confirm that
the API reports both memory metrics increase.  Simply confirming that it doesn’t decrease does
not prove much.  If the API was broken, it might report the same value every time and your
version of the test would pass (at least for the Max value).

If it proves to be too difficult to allocate enough memory to see the Max value increase without getting
an OOM, then we might have to consider removing that part of the test.  You might have to adjust the
min & max Heap sizes in order to ensure that pages are allocated during the test causing the Max
memory size to increase.


Bob.


> 
> 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
> 



More information about the hotspot-dev mailing list