Repository navigation
Support configurable initial/minimum heap size relative to (/as a percentage of) calculated Xmx #1377
Description
In the 3.x line of the buildpack, config/open_jdk_jre.yml supported a memory_initials mapping, allowing the initial size of each memory region (heap, permgen, metaspace) to be configured as a percentage of its calculated maximum. (https://github.com/cloudfoundry/java-buildpack/blob/3.x/docs/jre-open_jdk_jre.md). This option no longer appears from v4.0 onward (2017), including the current Go-based v5.x buildpack.
Because -Xmx is only known at container start (it depends on the memory limit assigned to the app instance), we cannot set a matching or proportional -Xms value ourselves via JAVA_OPTS, because we'd need to know the calculated -Xmx ahead of time. In practice this means our JVMs start with a small default initial heap and grow it under load, causing avoidable heap-resize activity that didn't happen back when memory_initials was available.
Could memory_calculator support such an option again to set the initial heap size as a percentage of the calculated max heap? This would let us keep using the automatic memory calculation while avoiding heap growth pauses after startup.
Activity
stokpop commentedon Aug 27, 2026
Hi @kjmeijvogel, thanks for the suggestion. Would explicitly setting Xms by the memory calculator be enough? The java memory calculator already does the job of determining the "percentage" to use for the Xmx of the total available container memory.
This would prevent the JVM memory growth effects you mention.
See also this discussion: cloudfoundry/java-buildpack-memory-calculator#33
kjmeijvogel commentedon Aug 27, 2026
Hey @stokpop. Are you suggesting to set the Xms at the same value as the calculated Xmx? If so, from what I've seen in the past, this could work fine as a default. That would prevent the heap from growing over time. Not sure if there could be situations where it would be preferable to use a lower Xms value than the Xmx value, but higher than the default initial size an app uses. If so, being able to set an initial heap size as a percentage of the calculated max heap would be the better solution. Ofcourse you can still override the Xms manually, but the issue remains that you don't know the Xmx upfront.
stokpop commentedon Aug 27, 2026
Yes, in my humble opinion setting Xms equal to Xmx (with the calculated value) would be the most simple solution to prevent the initial growth hickups.
There have been discussions about this in the past, and Xms was deliberately removed from the memory calculator before. Not sure if those arguments and behaviors from 2017, 2020 still hold today.
What about the recent suggestion from 2025 in the mentioned discussion: make Xms equal to Xmx, with a memory calculator option to turn on setting the Xms explicitly (default off?).
kjmeijvogel commentedon Aug 27, 2026
Not the most flexible solution, but a better option than not setting it at all from my perspective.
But if you set it to the same value as xmx by default, what about overcommitment? If there are other settings involved (like direct memory allocation) that theoretically leads to overcommitting the memory, but not yet in practice because the initial heapsize is low, that would then probably mean that there will be overcommitment at the start of the app already, so I guess it won't start up at all? One could wonder what's worse; knowing this already at the start or all of a sudden a OOM under load, but still... debatable I guess.
stokpop commentedon Aug 28, 2026
The memory calculator takes care of the direct memory setting (and others): it detects the setting and uses it in its calculation for xmx to keep it within the container memory.
Maybe better to continue this conversation in the memory calculator repo, we can re-open: cloudfoundry/java-buildpack-memory-calculator#33?