java/util/Base64/TestEncodingDecodingLength.java ran out of memory

The following test failed in the JDK20 CI:

java/util/Base64/TestEncodingDecodingLength.java

Here's a snippet from the log file:

#section:main
----------messages:(6/293)----------
command: main -Xms6g -Xmx8g TestEncodingDecodingLength
reason: User specified action: run main/othervm -Xms6g -Xmx8g TestEncodingDecodingLength
started: Tue Oct 11 10:38:27 UTC 2022
Mode: othervm [/othervm specified]
finished: Tue Oct 11 10:38:35 UTC 2022
elapsed time (seconds): 7.182
----------configuration:(0/0)----------
----------System.out:(5/348)*----------
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 2147483648 bytes for G1 virtual space
# An error report file with more information is saved as:
# C:\\sb\\prod\\1665484579\\testoutput\\test-support\\jtreg_open_test_jdk_tier1_part2\\scratch\\0\\hs_err_pid137880.log
----------System.err:(1/202)----------
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000780000000, 2147483648, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
----------rerun:(41/4713)*----------

Please note that the test has these:

 * @requires (sun.arch.data.model == "64" & os.maxMemory >= 10g)
 * @run main/othervm -Xms6g -Xmx8g TestEncodingDecodingLength

This test was executed as part of the "open/test/jdk/:tier1_part2"
test task. However, the test suite was run with a concurrency of 6:

Executing: [( bash /cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-20+19-1336/src.full/open/make/scripts/fixpath.sh exec /cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk/19/36/bundles/windows-x64/jdk-19_windows-x64_bin.zip/jdk-19/bin/java -Xms64M -Xmx1600M -Duser.language=en -Duser.country=US -Xmx768m -Djava.library.path="/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-20+19-1336/windows-x64.test/failure_handler" -Dprogram=jtreg -jar /cygdrive/c/ade/mesos/work_dir/jib-master/install/jtreg/7/1/bundles/jtreg-7+1.zip/jtreg/lib/jtreg.jar -vmoption:-Xmx768m -agentvm -verbose:fail,error,time -retain:fail,error -concurrency:6 -timeoutFactor:4 -vmoption:-XX:MaxRAMPercentage=4.16667 -vmoption:-Djava.io.tmpdir="/cygdrive/c/sb/prod/1665484579/testoutput/test-support/jtreg_open_test_jdk_tier1_part2/tmp" -automatic -ignore:quiet -e:JIB_DATA_DIR -e:_NT_SYMBOL_PATH -ea -esa -nativepath:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-20+19-1336/windows-x64.test/jdk/jtreg/native -exclude:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-20+19-1336/src.full/open/test/jdk/ProblemList.txt -e:JIB_HOME=/cygdrive/c/ade/mesos/work_dir/jib-master/install/com/oracle/java/jib/jib/3.0-SNAPSHOT/jib-3.0-20220830.222545-497-distribution.zip/jib-3.0-SNAPSHOT-distribution -e:TEST_IMAGE_DIR=/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-20+19-1336/windows-x64.test -k:'!headful' -testjdk:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-20+19-1336/windows-x64.jdk/jdk-20 -dir:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-20+19-1336/src.full -reportDir:/cygdrive/c/sb/prod/1665484579/testoutput/test-results/jtreg_open_test_jdk_tier1_part2 -workDir:/cygdrive/c/sb/prod/1665484579/testoutput/test-support/jtreg_open_test_jdk_tier1_part2 ${JTREG_STATUS} -timeoutHandlerDir:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-20+19-1336/windows-x64.test/failure_handler/jtregFailureHandler.jar -observerDir:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-20+19-1336/windows-x64.test/failure_handler/jtregFailureHandler.jar -timeoutHandler:jdk.test.failurehandler.jtreg.GatherProcessInfoTimeoutHandler -observer:jdk.test.failurehandler.jtreg.GatherDiagnosticInfoObserver -timeoutHandlerTimeout:0 open/test/jdk:tier1_part2 && echo $? > /cygdrive/c/sb/prod/1665484579/testoutput/test-results/jtreg_open_test_jdk_tier1_part2/exitcode.txt || echo $? > /cygdrive/c/sb/prod/1665484579/testoutput/test-results/jtreg_open_test_jdk_tier1_part2/exitcode.txt )]

so this test has to share memory with up to 5 other tests...

I don't know if the "open/test/jdk/" section of tests has a way
to isolate resource hogs, but this test might need to move
to a resource hogs list where it is run by itself.


Here's some snippets from the hs_err_pid file:

# Native memory allocation (mmap) failed to map 2147483648 bytes for G1 virtual space

so we tried to allocate just 2GB and:

Time: Tue Oct 11 11:38:33 2022 /GM elapsed time: 5.727930 seconds (0d 0h 0m 5s)

we were only running for 5 seconds so I'm guessing this is a fairly early heap expansion allocation.

And at the bottom of the hs_err_pid:

Memory: 4k page, system-wide physical 24575M (3796M free)
TotalPageFile size 28671M (AvailPageFile size 3491M)
current process WorkingSet (physical memory assigned to process): 5723M, peak: 5723M
current process commit charge ("private bytes"): 6399M, peak: 8423M

So we have 3.7GB free in RAM and 3.4GB free in swap so I'm not quite sure why we couldn't allocation 2GB. Perhaps both RAM and swap are fragmented or some other test that was running in parallel just finished while we were assembling the hs_err_pid info... Dunno.