Bug ID: JDK-8199265 java/util/Arrays/TimSortStackSize2.java fails with OOM

Versions (Unresolved/Resolved/Fixed)

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 11	JDK 12	JDK 8	Other
11 b20Fixed	12Fixed	8u421Fixed	openjdk8u302Fixed

After JDK-8190679 has been fixed 
java/util/Arrays/TimSortStackSize2.java started to fail with OOM:

Command line: [/scratch/opt/mach5/mesos/work_dir/jib-master/install/2018-03-02-2050320.vm-sqe-notifications_ww_grp.pit180301/linux-x64-debug.jdk/jdk-11/fastdebug/bin/java -XX:MaxRAMPercentage=6 -ea -esa -Xmx512m -Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation -XX:+IgnoreUnrecognizedVMOptions -XX:+AggressiveOpts -XX:-UseBiasedLocking -Xms385m -Xmx385m TimSortStackSize2 67108864 ]
TimSort OK. Time: 39375546772ns
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at TimSortStackSize2.createArray(TimSortStackSize2.java:209)
	at TimSortStackSize2.doTest(TimSortStackSize2.java:104)
	at TimSortStackSize2.doTestOfTwoTimSorts(TimSortStackSize2.java:90)
	at TimSortStackSize2.main(TimSortStackSize2.java:54)

Review approval: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-March/013553.html
18-03-2021
Fix Request (JDK8u) Request for a JDK8u-friendly version of this changeset to be backported to JDK8u as part of a set of changes to prevent an OOM being thrown during a -XX:-UseCompressedOops run (See JDK-8263099). https://cr.openjdk.java.net/~phh/8199265/webrev.8u.jdk.01/ The only real change made to the changeset was the use of ProcessTools.executeTestJvm instead of ProcessTools.executeTestJava. This was done because JDK8u's ProcessTools class lacks the executeTestJava method, and executeTestJvm appears to do the same thing. Note: Please merge this backport after the backports in 8190679 and 8075071, as this change depends on those. https://bugs.openjdk.java.net/browse/JDK-8190679 https://bugs.openjdk.java.net/browse/JDK-8075071
15-03-2021
[~amlu], moving it back to tier1 would require getting evidence that the test is stable again, which we don't have in JDK11 TF. as the test is now marked w/ intermittent k/w, it should be handled as any other intermittent tests, e.g. get it passed N same binaries runs in a row.
27-06-2018
URL: http://hg.openjdk.java.net/jdk/jdk/rev/9b0e2937fac5 User: iignatyev Date: 2018-06-27 20:46:21 +0000
27-06-2018
[~iignatyev] And move it back to tier1 in this fix?
27-06-2018
http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/033309.html
27-06-2018
Change from JDK-8190679 cause the problem: - .createJavaProcessBuilder(Utils.addTestJavaOpts(xmsValue, + .createJavaProcessBuilder(Utils.addTestJavaOpts(xmsValue, xmxValue, So for the same testing, after JDK-8190679, test run with: -Xms385m -Xmx385m but before JDK-8190679, test run with: -Xms385m This changed the purpose of test's usage of -Xms (with different value by determining whether testing with UseCompressedOops) but without -Xmx (ergonomics will select a maximum heap size), see more: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032346.html
08-04-2018

Relates :	JDK-8201766 - Mark TimSortStackSize2.java as intermittently failing
Relates :	JDK-8210353 - Move java/util/Arrays/TimSortStackSize2.java back to tier1
Relates :	JDK-8190679 - java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"