RFR (XXS): 8024669 Native OOME when allocating after changes to maximum heap supporting Coops sizing on sparcv9

[Thomas Schatzl]

Hi all,

  can I get some reviews for this very small change? It fixes the
HeapBaseMinAddress for solaris/sparcv9 so that when using ergonomics to
size the heap there will be enough memory for heap allocation.

The problem is that since JDK-8010722 the maximum heap size for
compressed oops is calculated more tightly, i.e. returning a larger
memory size for the maximum heap usable for zero based compressed oops.

Which, in case of solaris/sparcv9 causes problems, since the current
default HeapBaseMinAddress corresponds exactly to where the OS typically
maps the java executable to. Since the Solaris malloc implementation
puts the heap between the java image base address and the heap base
address, there is only very little space left (and Solaris' malloc
cannot use multiple virtual address ranges).

Previously this worked anyway because the calculation for the heap size
for zero based compressed oops returned a too small value, that resulted
in "enough" space, which is not the case any more.

This causes applications that do not specify Xmx and the actual physical
memory size is >= 32GB to fail at startup.

The proposed fix is to increase the default HeapBaseMinAddress to 6G (4G
previously), by default sort of reserving 2G for the C heap allocator,
similarly to others.

During testing this I found out that the calculation for the maximum
heap size for zero based compressed oops is buggy, I created the new CR
JDK-8024925 for that.

bugs.openjdk link:
https://bugs.openjdk.java.net/browse/JDK-8024669

Webrev:
http://cr.openjdk.java.net/~tschatzl/8024669

Testing:
jprt, testing is provided by running the jtreg test for 8010722.

Thanks,
  Thomas