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

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Sep 17 17:17:42 UTC 2013



On 9/17/13 5:48 AM, 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

More information about the hotspot-gc-dev mailing list