Heap Size Ergonomics and CompressedOops
bob.vandette at oracle.com
Thu Nov 1 14:04:41 UTC 2018
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