RFR(XS):JDK-8219228: java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test machine.

Zeller, Arno arno.zeller at sap.com
Tue Feb 19 12:25:31 UTC 2019


Hi Nishit,

thanks for testing!

Best regards,
Arno

>-----Original Message-----
>From: Nishit Jain <nishit.jain at oracle.com>
>Sent: Dienstag, 19. Februar 2019 10:05
>To: Zeller, Arno <arno.zeller at sap.com>; core-libs-dev <core-libs-
>dev at openjdk.java.net>
>Subject: Re: RFR(XS):JDK-8219228:
>java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test
>machine.
>
>Hi Arno,
>
>Although I don't know if turning off or no swap is expected for a test
>environment, but tried reproducing the issue locally on a 8Gb Ubuntu
>linux VM with swap turned off, the test case was passing until I started
>some other app (like browser) in parallel, in which case it failed with
>error = "Not enough space". Since it is a memory intensive test, I think
>it is better and safe to increase "os.maxMemory" check
>
>Change looks good to me, I am not an openJDK reviewer though.
>
>Regards,
>Nishit Jain
>On 18-02-2019 18:19, Zeller, Arno wrote:
>> Hello!
>>
>> I found that the test java/util/Base64/TestEncodingDecodingLength.java
>fails on a machine with 8GB memory after JDK-8218265.
>> The test starts a VM with -Xmx8GB but the VM needs some more memory
>than only the heap and on machines with just 8GB of memory (and no swap
>configured) the test will always fail because the VM cannot get enough native
>memory.
>> Therefore I suggest to increase "@requires os.maxMemory" to  >= 10GB to
>be safe.
>>
>> Could someone please review this minimal change?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219228
>>
>> Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8219228/
>>
>> Thanks and best regards,
>> Arno
>>



More information about the core-libs-dev mailing list