Enabling CompressedOops can restrict the size of the native heap that an application gets access to. Based on the heap size, the JVM can allocate java heap below 4GB or 32GB in order to use 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 java heap is placed below 4GB then the application can make around 2GB of native allocations even if there is 100s of GB available on the system. For applications that have small java heaps but need larger space for native allocations fail with native out-of-memory errors.

Currently, the available solutions to leave bigger space 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://blogs.oracle.com/poonam/running-on-a-64bit-platform-and-still-running-out-of-memory

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 goal of users is to be able to specify the size of the native allocations that their applications can make, and not figure out how and where the JVM places their java heap. It would be helpful to have an additional 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 java heap.