RFR (XXS): 8024669 Native OOME when allocating after changes to maximum heap supporting Coops sizing on sparcv9
bengt.rutisson at oracle.com
Wed Sep 18 10:14:20 UTC 2013
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:
> jprt, testing is provided by running the jtreg test for 8010722.
More information about the hotspot-gc-dev