RFR: 8213175 - MaxHeapSize refuses to go over 32178700288 when running in a docker container
thomas.schatzl at oracle.com
Tue Mar 19 21:42:36 UTC 2019
first, sorry for the delay in answering.
On Thu, 2019-03-14 at 16:51 -0400, Bob Vandette wrote:
> Thanks for the feedback Thomas.
> You are correct that the change I implemented will cause us to select
> non coop mode rather than cap the size of the heap. This was not my
> intention. This Heap Size flag processing in Hotspot is non
> intuitive. We make a decision to turn on UseCompressedOops based on
> the default value of MaxHeapSize (96MB on x64) but then look at the
> real amount of memory in the system and then assume we want to keep
> coops on rather than use a potentially much larger heap.
Because for most applications coops (and a smaller heap) is preferable
to a large heap.
This is the case typically used by people that just want to run a small
> My implementation does all the heap sizing and then determines if we
> can enable CompressedOops based on the size we determined.
> The change that I had hoped to implement only disables coop mode if
> the user specifies MaxRAMPercentage. The justification is that if
> the user specified this flag, they want this behavior over other
> conflicting ones.
> I’ll try to refine my implementation to end up with a less invasive
> See more comments below ...
> > On Mar 14, 2019, at 7:19 AM, Thomas Schatzl <
> > thomas.schatzl at oracle.com> wrote:
> > Hi,
> > This is a significant externally visible change to behavior, so
> > this needs a CSR regardless of pre-existing intended behavior or
> > not.
> I will file a CSR once I settle on an implementation.
> > This RFR does not give performance numbers. Did you check for
> > performance regressions in our benchmark suites?
> Please send me a private email on how to run the benchmarks you
> are concerned with.
More information about the hotspot-runtime-dev