Currently, our Docker images will always launch the JVM in the container using Xmx and Xms flags, with a default value if the user doesn't not specify the appropriate env vars.

However, this doesn't give the JVM any chance to make an informed decision on its own, using the container's cgroups memory allocation. Since Java10, The JVM will auto-detect the cgroups allocation and allocate max heap accordingly - unless you override that with Xmx and Xms.

My suggestion is to provide a new environment variable, JVM_AUTO_MEMORY for example, which will omit the -Xmx and -Xms command line arguments to the JVM, and let the JVM pick its own value based on the container's constraints. Ideally, this would be the default behaviour, but we need to support the existing Xmx and Xms defaults.

For extra points, add another env var to support the -XX:MaxRAMPercentage flag, which overrides how much of the container's available memory will be allocated to the heap (it seems to default to 50%).

The result of this change would be to manage the JVM's memory sizing via container restrictions, rather than specifying it in the JVM. This is particularly compelling for Kubernetes environments, where admins want to allocate resources to the pods' containers, and have the JVM honour that, without having to dive down into Xmx and Xms configuration.