Summary

The proposed change is to add a new JVM option, -XX:NativeHeapSize=n, to specify the size of the native heap accessible to a Java process.

Problem

Enabling CompressedOops can restrict the size of the native heap that a Java application can access. Based on the heap size requirement, the JVM can allocate Java heap below 4GB or 32GB in order to use the zero based compressed oops. The placement of Java heap in the virtual address space determines how much native heap gets left for native allocations. For example, if the Java heap is placed below 4GB then the application can make only around 2GB of native allocations, even when there might be 100s of GB available on the system. For applications that have relatively small Java heaps but need larger space for native allocations can fail with native out-of-memory errors.

Currently, the available solution for leaving larger room for native heap is to either disable CompressedOops, or use the JVM option -XX:HeapBaseMinAddress that allows to specify the base address for Java heap. More details here: https://poonamparhar.github.io/out_of_memory_on_64_bit_platform/

With -XX:HeapBaseMinAddress, by specifying a higher virtual address, it is possible to leave desired amount of space for potential native allocations. However, it is not very intuitive and requires users to perform some calculations to determine an appropriate value for this option.

The users should be able to specify the size of native allocations that their applications can make, and not worry about how and where the JVM places Java heap. It would be helpful to have a new JVM option, say -XX:NativeHeapSize=n to specify the native heap size that an application would like to have for native allocations. Based on the value of this option and the Java heap size, the JVM then should determine the base address of the Java heap.

Solution

Add a new JVM option, -XX:NativeHeapSize, to specify the size of the native heap for Java applications.

Specification

While initializing the Java Heap space for compressed oops, the JVM determines its base address by looking at the heap size and the HeapBaseMinAddress value.

The relevant source code is here: https://github.com/openjdk/jdk/blob/becee6435bc38c4e3fe5b197c985e68e97fc8e0d/src/hotspot/share/memory/virtualspace.cpp#L516

The following blog post explains in detail as to how the JVM determines the base address of the Java Heap while working with CompressedOops: https://shipilev.net/jvm/anatomy-quarks/23-compressed-references/

The current implementation should consider the value specified with the new option (-XX:NativeHeapSize) along with the heap size to determine the base address for the Java Heap. Note that the value of the new option would take precedence over HeapBaseMinAddress.