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.

apply_ergo
  set_ergonomics_flags
    set_use_compressed_oops
  set_heap_size 

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.

Comments?

Bob.




More information about the hotspot-gc-dev mailing list