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

[Bengt Rutisson]

Thomas,

Looks good.

Bengt

On 9/17/13 2:48 PM, Thomas Schatzl wrote:
> 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
>
>