Heap Size Ergonomics and CompressedOops

[Thomas Schatzl]

Hi,

On Thu, 2018-11-01 at 10:04 -0400, 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?

Afair the behavior that automatic heap sizing stays below the
UseCompressedOops range has been an intentional design decision if you
do not explicitly set a heap size larger.

For the far majority of VM invocations it is very probable that users
(still) appreciate the performance gains of compressed oops and
actually do not need a Java heap outside this range.

Just the historical view, not particularly against changing this, but
we need to consider that this may have unintended (performance)
implications running small programs on large machines.

Thanks,
  Thomas