Many JVMs deployed today run in containers. Specifically deployed in containers on orchestration frameworks such as Kubernetes. Such frameworks recommend setting memory requests[1] for node scheduling purposes. If the user sets memory request and a limit[2] the JVM will detect it. The common expectation is that such JVMs run as PID 1 (single process) on those containers with the assumption to use the set memory slice by the deployment config.

However, the JVM still runs with a default MaxRAMPercentage of 25% of available physical memory. That means, if the JVM runs in a container on k8s with a memory limit, physical memory will be the set container limit. Then the heap size will be determined by MaxRAMPercentage and other factors. In most cases the JVMs heap size will be ~25% of physical memory. This makes sense for multi-user systems where many processes compete for memory. Not so much for the containerized deployment scenario as described in this issue. In the containerized deployment scenario it likely means that the default heap size will be too small, thus, underutilizing memory in the container.

The default heap size based on the MaxRAMPercentage value should get increased for containerized workloads. OSContainer::is_containerized() API could be used to adjust MaxRAMPercentage in that case.

[1] https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
[2] https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#example-1