JDK-8295153 : java/util/Base64/TestEncodingDecodingLength.java ran out of memory
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 20
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2022-10-11
  • Updated: 2024-07-08
  • Resolved: 2024-05-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 23
23 b22Fixed
Related Reports
Relates :  
Relates :  
Description
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.
Comments
Changeset: b33096f8 Author: Justin Lu <jlu@openjdk.org> Date: 2024-05-03 16:58:59 +0000 URL: https://git.openjdk.org/jdk/commit/b33096f887108c3d7e1f4e62689c2b10401234fa
03-05-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/19036 Date: 2024-05-01 16:10:06 +0000
01-05-2024

The JBS issues references in the bug tag should help get some background. I remember there were issues where the decoder threw NegativeArraySizeException or some other expectation when there was overflow and it should have thrown OOME.
12-10-2022