Heap Size Ergonomics and CompressedOops

[Stefan Johansson]

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.
> 
> 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?

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.

Thanks,
Stefan
> 
> Bob.
> 
>