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:23:40 UTC 2019
Should you continue waiting in the loop until BOTH the new usage and max usage exceed their
initial values?
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