Heap Size Ergonomics and CompressedOops
stefan.johansson at oracle.com
Thu Nov 1 14:52:17 UTC 2018
On 2018-11-01 15:04, Bob Vandette wrote:
> 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.
Sounds like a good approach, after a brief look at the code it feels
like it should be cleaned up even more but that is a separate task.
Regarding warning the user, I think this is good if we have conflicting
options like -Xmx64g and -XX:+UseCompressedOops, but not if the user
only supplied -Xmx64g.
There are some tests under serviceability/tmtools that I know they have
failed in the past when touching the heap sizing code, so they might be
good to run.
More information about the hotspot-gc-dev