RFR: 8213175 - MaxHeapSize refuses to go over 32178700288 when running in a docker container

[Bob Vandette]

> On Mar 13, 2019, at 12:40 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Bob,
> 
> On 13/03/2019 1:04 am, Bob Vandette wrote:
>> Please review this fix for correcting the Heap size when MaxRAMPercentage is used.
>> BUG:
>> https://bugs.openjdk.java.net/browse/JDK-8213175
>> WEBREV:
>> http://cr.openjdk.java.net/~bobv/8213175/webrev.0/
>> SUMMARY:
>> This fix changes the ordering of when we try to determine if we can
>> enable UseCompressedOops.  It is now done after more of the Heap size
>> calculations are completed.
>> The only behavioral change should be that UseCompressedOops will now be
>> disabled if someone specifies a MaxRAMPercentage that causes the heap size
>> to exceed the amount of memory that can be used with compressed oops.
>> Prior to this change, the amount of heap was reduced to the compressed oop
>> limit.
> 
> It isn't at all clear to me that this is the correct fix here. Why not assess this as "not an issue" and require the user to disable compressed oops?

The reason that I didn’t take that path is that I believe the new behavior was the intention of the original author.
The comment at line 1614 states that InitialHeapSize was the only option that could impact MaxHeapSize
but the author was wrong.  The HeapRatio and now the HeapPercentage options impact MaxHeapSize as well
and weren’t taken into consideration.


1611 void Arguments::set_use_compressed_oops() {

1612 #ifndef ZERO
1613 #ifdef _LP64

1614   // MaxHeapSize is not set up properly at this point, but
1615   // the only value that can override MaxHeapSize if we are
1616   // to use UseCompressedOops is InitialHeapSize.
1617   size_t max_heap_size = MAX2(MaxHeapSize, InitialHeapSize);
1618 

> 
> Such a behaviour change needs to be discussed and needs a CSR request.

Let’s see what the GC team wants me to do here.  

Bob.


> 
> David
> 
>> Bob.