Heap Size Ergonomics in docker containers

[Thomas Schatzl]

On Tue, 2017-10-24 at 14:43 -0400, Bob Vandette wrote:
> I’m trying to test the container support that I’m adding to 
> JDK 18.3 and I’m running into an issue with the Heap size
> calculation.
> 
> If I create a docker container that has 100MB of total memory on a
> 64-bit Linux box, I’m ending up with a 126MB Max Heap which results
> in the process getting killed by the OOM killer.
> 
> This is due to the fact that MaxHeapSize is 126MB and phys_mem
> (100MB) is
> not less than 50% of MinRAMPercentage of MaxHeapSize.
> 
> I would think in a small memory system, you don’t ever want the Heap 
> size to be more than somewhere around 70% of total RAM.  
> 
> A quick fix for my problem might be this, but this still
> leaves some pathological cases where phys_mem is greater than but
> close to MaxHeapSize.
> 
> if phys_mem < MaxHeapSize || phys_mem < MaxHeapSize *
> MinRAMPercentage
>    use phys_mem * MinRAMPercentage
> 
> I could improve on this with:
> 
> if MaxHeapSize > 70% of phys_mem || phys_mem < MaxHeapSize *
> MinRAMPercentage
>    use phys_mem * MinRAMPercentage
> 
>  [...]
> Let me know what you think.  
> 

  that seems to be almost the same as making the default value of
MaxHeapSize 70% smaller. Also that 70% only seems to serve the same
purpose as MaxRAMPercentage, i.e. imo MaxRAMPercentage should have
covered that.

I kind of question this line in the code:

      // Not-small physical memory, so require a heap at least
      // as large as MaxHeapSize
      reasonable_max = MAX2(reasonable_max, (julong)MaxHeapSize);

So we just found out a "reasonable max" as a part of the calculation,
and then we ignore it...

The problem seems to be the default value of MaxHeapSize being 126M for
64 bit machines. I guess this has been made to provide a "good Java
experience" with machines with only a few 100 MBs (overriding
MaxRAMPercentage). From that point of view, I am not sure why the
default value is that large given typical (PC) memory sizes nowadays.

So one option could be reducing the default MaxHeapSize to some lower,
other random value (E.g. the absolute minimum it needs to run a Hello
World program plus some buffer for good measure)

Then again, the given 126MB as absolute minimum seems to be as good as
any other value (96MB for 32 bit systems) - everyone else just needs to
set -Xmx. I mean, if the next person wants to run the VM in a 50M
docker container, and defaults fail, the same complaints will start
again, so as long as the MAX2() calculation is there any random minimum
heap size will cause this issue.

So another option would be to remove that MAX2 calculation...

  Thomas