RFR: 8350596: [Linux] Increase default MaxRAMPercentage for containerized workloads

[Stefan Johansson]

On Wed, 7 May 2025 09:29:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please take a look at this proposal to fix the "Java needs so much memory" perception in containers. The idea would be to bump the default `MaxRAMPercentage` to a higher value. The patch proposes 75%, but we could just as well use 50% if people feel more comfortable about it. Right now the default deployment in containers with resource limits in place (common for Kubernetes deployments) where a single process runs in the container isn't well catered for today for an application that just uses the default configuration. Only 25% of the container memory will be used for the Java heap, arguably wasting much of the remaining memory that has been granted to the container by a memory limit (that the JVM would detect and use as physical memory).
> 
> I've filed a CSR for this as well for which I'm looking for reviewers too and intend to write a release note as well about this change as it has some risk associated with it, although the escape hatch is pretty simple: set `-XX:MaxRAMPercentage=25.0` to go back to the old behavour.
> 
> Testing:
> - [x] GHA - tier 1 (windows failures seem infra related)
> - [x] hotspot and jdk container tests on cg v2 and cg v1 including the two new tests.
> 
> Thoughts? Opinions?

Thanks for looking into this Severin.

Thinking back to the discussions we had around this at OCW, I remember there were some concerns regarding different types of deployments. I think this really makes sense in the cases where we divide a machines memory using containers, but what if containers are just used to divide other resources. One use-case that was raised was containerized applications on Linux. I'm not sure if such an application would report true for `is_containerized()`, but it would be nice to have some data around this. Have you done any testing with containerized apps?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-2865246427