JDK-8073354 : [TEST_BUG] TimSortStackSize2.java: test cleanup: make test run with single argument
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-02-17
  • Updated: 2016-06-13
  • Resolved: 2015-02-26
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 7 JDK 8 JDK 9
7u85Fixed 8u60Fixed 9 b53Fixed
Related Reports
Duplicate :  
JDK-8073959 - java/util/Arrays/TimSortStackSize2.java fails with java.lang.OutOfMemoryError: Java heap space when running without CompressedOops
Duplicate :  
JDK-8073124 - Tune test and document TimSort runs stack size increase
Description
instead of closing this bug as dup of JDK-8073124 I'll use this bugID(JDK-8073354) to perform cleanup in this test in such way:
  - make it run with a single argument '67108864' by moving @summary tag
strait down to line after the @run tag
  - '-Xmx385' ->'-Xms385' in run command. MaxHeapSize will adjust accordingly.
  - spaces and code style
Comments
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031628.html
19-02-2015
256 Mb for client: $ jdk9/bin/java -XX:+PrintGC -XX:+PrintGCDetails -client -XX:+PrintFlagsFinal TimSortStackSize2 67108864 | grep -i MaxHeapSize uintx MaxHeapSize := 268435456 {product} but test requires 385. $ jdk9/bin/java -XX:+PrintGC -XX:+PrintGCDetails -client -XX:+PrintFlagsFinal -Xms385m TimSortStackSize2 67108864 | grep -i MaxHeapSize uintx MaxHeapSize := 404750336 {product}
19-02-2015
My last comment may seem out of context since I wrote it before I saw your last comment Lev. Trying anain :) I would suggest you run with -XX:+PrintFlagsFinal to see what MaxHeapSize is set to. It's the only way to be sure.
19-02-2015
The mail suggests to remove -Xmx. That's probably not what you want if you want to make sure there is enough Java heap space for the test. If the test needs 385MB of heap, it will need it wether -Xmx is set or not. I haven't looked at the test in question, but unless it is testing default values of -Xmx, my recomendation is to always set it to remove one variable that may cause the test to fail due to environment issues. If set to a sufficiently large number you will see the difference between native out of memory (crash) and Java heap out of memory (OOME). If it is not set the maximum heap size may be configured too small on hosts with little memory and cause the test to get OOME due to lack of physical memory. You don't want that. Physical memory fragmentation would still lead to a VM error (crash) though, even if -Xmx is set too small.
19-02-2015
Thanks [~jwilhelm], Test passes on 8Gb laptop with default heap size ergonomics. And also with explicitly -Xmx385m: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1d4b8b0f6f7 . May ergonomic choose smaller(<385Mb) max amount of heap on 252Gb machine ?
19-02-2015
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031625.html
19-02-2015
Native memory fragmentation would give a VM error (the VM aborts with an error message if it fails to commit heap memory). Fragmentation in the Java heap would lead to a full GC. OOME means that there is not enough heap available after a full GC. Maybe the test hit -Xmx. There is always an upper limit even if the flag is not set explicitly, use -XX:+PrintFlagsFinal to see what it is (it varies depending on environment). You can also use -XX:+PrintGC or -XX:+PrintGCDetails to get logs from the GCs and see the actual heap usage. If there seems to be enough space left but you still get an OOME, it could be a VM bug. Usually though it's the application that has more live data than what is obvious.
19-02-2015
JDK-8073124 adds explicit "-Xmx385m" OOME on creating array: Integer[] a = new Integer[67108864]; [[~dfazunen], May the memory on host be fragmentated ?
18-02-2015