JDK-8073959 : java/util/Arrays/TimSortStackSize2.java fails with java.lang.OutOfMemoryError: Java heap space when running without CompressedOops
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2015-02-26
  • Updated: 2015-03-12
  • Resolved: 2015-02-26
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
Reproduces easily using:
java -XX:-UseCompressedOops -Xmx385m TimSortStackSize2 67108864

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at TimSortStackSize2.createArray(TimSortStackSize2.java:168)
        at TimSortStackSize2.main(TimSortStackSize2.java:44)

Comments
updated review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031876.html
26-02-2015

I meant it passes, while I tested it locally: TimSort: 264438688 ComparableTimSort: 226445108
26-02-2015

I think it should work, it passed when running with a -Xmx around 950m.
26-02-2015

[~ctornqvi], Test will pass after applying cleanup from JDK-8073354 ( changing -Xmx385m to -Xms385m ) : $ ~/Downloads/9b51/bin/java -XX:-UseCompressedOops -Xms385m -XX:+PrintFlagsFinal -d64 -Xmixed -server TimSortStackSize2 67108864 | grep -i 'maxheap\|compress\|sort' uintx CompressedClassSpaceSize = 1073741824 {product} uintx MaxHeapFreeRatio = 100 {manageable} uintx MaxHeapSize := 1010827264 {product} bool UseCompressedClassPointers = false {lp64_product} bool UseCompressedOops := false {lp64_product} TimSort: 264438688 ComparableTimSort: 226445108 Is relying on chosen by default ergonomic value of MaxHeapSize robust enough ?
26-02-2015