Heap Size Ergonomics and CompressedOops

Bob Vandette bob.vandette at oracle.com
Thu Nov 1 14:04:41 UTC 2018

BUG: https://bugs.openjdk.java.net/browse/JDK-8213175
         MaxHeapSize refuses to go over 32178700288 when running in a docker container

The above bug is caused by the ergonomic logic that assumes that the MaxHeapSize does not
change once the set_use_compressed_oops function is executed.  This is not always the case.
If a user specifies MaxRAMPercentage, HeapBaseMinAddress, InitialHeapSize, the user will
not necessarily get what they want if they are requesting a heap size greater than can be supported
with compressed oops enabled.

We automatically disable UseCompressedOops if the user specifies a -Xmx value greater than
the compressed oops limit but not if the heap size is selected by other means.

Here’s the order of initialization.


I’d like to move the set_heap_size function above the set_use_compressed_oops.  This
will require some modifications to both set_use_compressed_oops and set_heap_size but
would result in a more consistent handling of this situation.  I’d also like to warn users if they
have selected values that result in CompressedOops being forced off.



More information about the hotspot-gc-dev mailing list